This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]