Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2

[Jim Blandy <jimb at zwingli dot cygnus dot com>]

> > 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.)