Date: Thu, 7 Dec 2000 19:20:28 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
cc: djgpp-workers AT delorie DOT com
Subject: Re: DJGPP linker script update
In-Reply-To: <Pine.LNX.4.10.10012071653470.18292-100000@acp3bf>
Message-ID: <Pine.SUN.3.91.1001207191541.29413E-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Thu, 7 Dec 2000, Hans-Bernhard Broeker wrote:

> That part of 'symify' which gives the real benefit of it already is in the
> binutils for quite a while: there's the addr2line tool that, given a list
> of addresses and the executable with debug info, prints the source line
> and file.

addr2line is badly broken, I needed to repair some of its code when I 
wrote bfdsymify (which is based on addr2line).  I don't remember the 
details, but it had to do with printing something reasonable for library 
functions for which there's no debug info in the executable.

> >  2. If the latter, do we have a volunteer to add core file support at 
> >     least for GNU/Linux? ;-)
> 
> That would probably be a reinvention of a wheel that already exists inside
> either BFD or GDB.

I meant to add core file support to bfdsymify, so that it would read the 
core file and print the stack traceback, exactly like GDB (or any other 
debugger) does on Unix.  AFAIK, this particular feature is not part of 
BFD, and GDB is IMHO too large to tell users to use it just to get a 
traceback.  (GDB also uses lots of its own code to read symbols, 
bypassing the equivalent BFD code.)