This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
Jim Blandy wrote:
>
> > > The whole address_significant_size code in dwarf2read.c strikes me as
> > > a rather ugly kludge to work around bugs elsewhere in the tool chain.
> > > If someone is supplying a 32 bit pointer to GDB on a 16 bit target,
> > > shouldn't the rest of the tool chain be responsible for making sure
> > > the high bits are zero rather than expecting GDB to mask it off?
> > > Granted there might be complications here, like there are cases on
> > > MIPS where we treat an address as signed rather than unsigned, but I'm
> > > also pretty clear on whether that is actually design or just a bug. I
> > > could be wrong/persuadable, of course, and perhaps someone has a
> > > better idea of all this (in which case I'd suggest commenting
> > > arch_size at bfd/elf-bfd.h and/or expanding comments at
> > > bfd_arch_bits_per_address in bfd/archures.c).
> >
> > FYI, in the MIPS case it is a feature of the hardware. GDB has little
> > choice in the matter.
>
> Can you explain why, in the MIPS case, GCC/GAS/LD are unable to place
> correct information in the upper bits of the Dwarf addresses?
>
> (That sounds like a rhetorical question, but it's not. I'm having a
> hard time imagining why address_significant_bits was the right
> solution.)
From memory, it isn't just the dwarf address. The information comes
from two places:
o the debug info
o the raw symbol table
the former has 64 bit information. The latter (elf32) has only 32 bit
information. 64bits don't fit into a 32 bit table. GDB uses both.
enjoy,
Andrew