delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/06/10/10:12:26

From: ian AT cygnus DOT com (Ian Lance Taylor)
Subject: Re: debugging
10 Jun 1998 10:12:26 -0700 :
Message-ID: <199806101702.NAA01860.cygnus.cygwin32.developers@subrogation.cygnus.com>
References: <m0yjnT1-00117AC AT malasada DOT lava DOT net>
To: newsham AT lava DOT net
Cc: cygwin32-developers AT cygnus DOT com

   From: newsham AT lava DOT net (Tim Newsham)
   Date: Wed, 10 Jun 1998 06:11:14 -1000 (HST)

	Gdb is currently lacking some very important features in cygwin.  I
   was wondering what would be needed to get these features put in.  The
   first is support for memory "core' dumps.  It would seem that the exception
   routines would just have to dump out the various sections of memory
   in a format that let gdb read them back in.  Of course this assumes that
   it can figure out where the sections of memory are (is there an easy
   way to do this?).  Then gdb would just have to read them back in to
   a debugged process.  This doesnt sound very hard, so I must be missing
   something :)  What are the hard problems here?

There are no hard problems.  It's just a lot of detail work.  You
would have to pick a core file format, change the cygwin DLL to write
it out, and then make sure that the BFD library can read it in into a
format which gdb is prepared to work with.  Advanced Windows by
Jeffrey Richter explains how to find out what is present in virtual
memory, and therefore should permit you to find the data and stack
sections which need to be written to the core file.

Many COFF based systems used the traditional Unix core file format
(bfd/trad-core.c) but I don't think that will be acceptable for
Windows, because it only permits a data section, a stack section, and
a register section.  Windows memory layouts are more complex.

   The second feature is the ability to attach to running processes.  Why
   is this harder than starting up a new debugged process.  (Note:  I'm not
   familiar with NT debugging facilities).

I don't know.

   Finally,  how much support is there for using windows debugging tools.
   Surely they must have been used to debug cygwin itself when it was first
   being brought up.  Is it possible to emit symbol tables that windbg can
   grok?  Does anyone have tips for using non-cygwin debuggers with cygwin?

I would not necessarily assume that Steve used Windows debugging tools
when developing cygwin32, although he may have.

gcc is not able to emit debugging information for windbg.  It might be
possible to convert gcc to do this.  It might also be possible to
teach objcopy how to translate gcc generated stabs information into
something that windbg can understand.  Either would be a fairly
difficult task.  I don't even know whether the windbg format is
documented.

Ian

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019