Date: Thu, 7 Dec 2000 17:24:40 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: "Mark E." cc: djgpp-workers AT delorie DOT com Subject: Re: DJGPP linker script update In-Reply-To: <3A2F5B2D.2111.D4E8D@localhost> 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, 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)?