Mail Archives: djgpp-workers/2000/11/25/22:39:28
> Btw, I see that Binutils 2.10.1 has been released. Are the patches
> significant enough to apply them?
I'm revisiting this since I've had a change to take a good look at 2.10. I've
found that only one of my post 2.10 fixes have been included. Therefore I
don't think it's worth the trouble to release a port of 2.10.1 since most of
the fixes are more than likely for the more popular platforms and my fixes
are already in the 2.10 port.
I also taken a look at what it would take to add dwarf2 support since I've
been hearing here and other places that it's supposed to be better than stabs
for C++ debugging. Configuring in dwarf2 support for gcc is rather trivial
(tested with gcc 2.95.2, since I won't be able to mess with CVS gcc until an
upcoming memory upgrade.).
Binutils will probably need some changes. One of the bigger changes will be
that binutils know how to set the right alignment for dwarf2 sections. The
DJGPP config can be changed to recognize these section names and set the
right alignment accordingly, but I think this is a bad way to go. Certain
sections have their alignment set accordingly based on their names because
currently there is no way to store the alignment (output from gcc using the
.p2align directive) like some flavors of COFF do. BTW, ELF has a field in the
section header to store the alignment information. If we allocate some of the
many unused bits in the section header flags to store the alignment, the
hooks are already present in binutils can be used to store/read these bits.
All that has to be done in DJGPP's config is tell binutils how the store/read
the alignment value. Then in the future special section names won't require
special handling by Binutils except perhaps with a linker script change.
I have no idea what changes gdb will require, but I assume the changes to the
binutils bfd library will go a long way toward supporting dwarf2 there too.
Mark
- Raw text -