Message-ID: <B0000069247@stargate.astr.lu.lv>
From: "Andris Pavenis" <pavenis AT lanet DOT lv>
To: Laszlo Molnar <laszlo DOT molnar AT eth DOT ericsson DOT se>, djgpp-workers AT delorie DOT com
Date: Mon, 1 Feb 1999 17:50:40 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: egcs patch
In-reply-to: <19990201142609.A20469@duna41>
References: <B0000069167 AT stargate DOT astr DOT lu DOT lv>; from Andris Pavenis on Mon, Feb 01, 1999 at 02:03:56PM +0200
X-mailer: Pegasus Mail for Win32 (v3.01d)
Reply-To: djgpp-workers AT delorie DOT com

On 1 Feb 99, at 14:26, Laszlo Molnar wrote:

> > > As I'm ready with the cross-binutils, I'll focus on hacking egcs ;-) I
> > > plan to reduce the size of the eh_frame info for djgpp...
> > Is it needed? GNU assembler already have eh frame optimization (works when
> > built as BFD assembler). Is it necessary to duplicate it somewhere else.
> 
> The EH frame optimization stuff in gas is nice, but there are still too
> much unused bytes in the eh_frame section. This dwarf2 frame info was
> invented to be used by debuggers, so it contains very detailed
> information about the program. Djgpp programs don't need lots of
> them.

What we will do when gdb will support C++ exceptions. Are we going to put
this information back then. Perhaps it's best not to touch eh_frame section
too much not to break things we may need later.
 
> > One more thing about BFD assembler. I found that using BFD assembler 
> > sometimes breaks fsdb and edebug32 which use COFF debugging info support
> > from src/debug/common/syms.c. I found it when tried to run gnuplot-3.7
> > built for DJGPP under fsdb: it simply crashed while loading  debugging info.
> > Tested: this problem disappears when I'm building assembler after configuring
> > binutils snapshot without option --enable-bfd-assembler. This problem appears
> > only sometimes (not for all executables)
> 
> So the snapshot is not stable enough yet. Sigh.

I don't think so. gdb (even DJGPP binaries of gdb-4.16)  takes such executable 
without problems. So I think BFD assembler does something slightly differently
and it breaks COFF debugging info support in libdbg.a (however this doesn't 
appear for all executables). I think primary is libbfd.a but not COFF support
in libdbg.a. 

Andris