Mail Archives: djgpp-workers/1999/02/01/10:51:35
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
- Raw text -