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 X-Sender: broeker AT acp3bf To: djgpp-workers AT delorie DOT com Subject: Re: DJGPP linker script update In-Reply-To: Message-ID: 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, 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.