Date:	Thu, 7 Dec 2000 17:24:40 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Mark E." <snowball3 AT bigfoot DOT com>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: DJGPP linker script update
In-Reply-To:	<3A2F5B2D.2111.D4E8D@localhost>
Message-ID:	<Pine.SUN.3.91.1001207170610.28444D-100000@is>
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, Mark E. wrote:

> > ???  Isn't GDB already configured to support dwarf2 (and many other
> > formats)?  When GDB is built for DJGPP, all the *read.c modules,
> > including dwarf2read.c, are linked in, IIRC.
> 
> You must excuse my ignorance of GDB, I know nothing of the GDB source.

That was more a question to others, like Andris and DJ, who know about 
GDB, probably more than I do.

I have always wondered why do we need all those *read.c modules linked 
into GDB and making it so large (the current version overflows the COFF 
limit of 64K lines for debug info).

> > What's the plans for SYMIFY?
> 
> I would suggest resurrecting bfdsymify and let bfd do the hard work because I 
> don't know anybody here than can handle the job.

I don't mind that (bfdsymify is in working order, so I don't need 
anything to resurrect it).  I just need to upgrade it to the improved 
display code written for SYMIFY that went into DJGPP v2.03.

However, switching to bfdsymify as our principal tool might need some 
more work, which I'd like to discuss.

The initial plan (suggested by DJ) was to donate bfdsymify to the 
Binutils package, and thus make sure we always have it in sync with the 
latest Binutils and whatever binary formats we support.

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

Questions:

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

 2. If the latter, do we have a volunteer to add core file support at 
    least for GNU/Linux? ;-)

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

- Raw text -