X-Authentication-Warning:	acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date:	Thu, 7 Dec 2000 17:02:32 +0100 (MET)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender:	broeker AT acp3bf
To:	djgpp-workers AT delorie DOT com
Subject:	Re: DJGPP linker script update
In-Reply-To:	<Pine.SUN.3.91.1001207170610.28444D-100000@is>
Message-ID:	<Pine.LNX.4.10.10012071653470.18292-100000@acp3bf>
MIME-Version:	1.0
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

On Thu, 7 Dec 2000, Eli Zaretskii wrote:

[...]
> The problem with that approach is that bfdsymify reads from the video 
> memory and optionally writes there.  This is inherently DJGPP-specific, 
> so either bfdsymify needs to be a DJGPP-specific program, or we need to 
> write a general-purpose code for other platforms.  

I doubt that would be possible at all. The only way of displaying a stack
backtrace, on all other gcc target platforms I've seen except DJGPP, is to
actually load a corefile into the debugger and type 'where'. I.e. no
platform I've seen except DJGPP writes the stack traceback and register
dump directly to screen.

>  1. Should we maintain bfdsymify as part of djdev, or extend it to be 
>     generally useful and donate it to Binutils?

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. Some utilities already use it (e.g. YAMD on Linux, IIRC).

>  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.

-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -