Message-ID: <3A2FD9C3.BB64BCDB@softhome.net>
Date: Thu, 07 Dec 2000 19:41:07 +0100
From: Laurynas Biveinis <lauras AT softhome DOT net>
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: lt,en
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: DJGPP linker script update
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1001207170610 DOT 28444D-100000 AT is>
Content-Type: text/plain; charset=iso-8859-4
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

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.  A DJGPP-specific
> program could easily become unmaintained, which in effect defeats the
> purpose of adding it to Binutils; we might as well maintain it as part of
> djdev.  Writing a general-purpose code... well, frankly, I simply don't
> know how to do that, or even whether it can be done, since the format of
> the stack traceback is platform-dependent, and some platforms don't have
> it at all (so we'd probably need to read the core file instead).

Is it possible to turn bfdsymify into a library which takes executable file
name, list of addresses in trace, returns symified info, and submit for
binutils that? And maintain a smaller DJGPP-specific front-end which does 
screen reads, writes etc. Of course, I might be missing a fact, that bfdsymify
is already very DJGPP specific front end for libbfd.

>  3. What are our chances to get bfdsymify accepted by the Binutils
>     maintainer(s)?

Why not to ask them instead of guessing? ;-)

Laurynas