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

[Andrew Cagney <ac131313 at cygnus dot com>]

Jim Kingdon wrote:
> 
> > When I say  ``elf16'', I was thinking of an elf object file that has 16
> > bit addresses.  I'm not sure what other consequences such a move would
> > have.
> 
> Strikes me as a bad idea.  Or to put it another way, designing a
> hypothetical elf16 format seems like something you'd do only if you
> had pretty compelling reasons, not just to fix a GDB bug which can be
> fixed in much simpler ways.

I'm not sure that there is a GDB bug - GDB appears to have been given
wrong information.

> > Is there any reason why s->arch_size isn't 16 in your case?

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

	enjoy,
		Andrew