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

[Stephane Carrez <Stephane dot Carrez at worldnet dot fr>]

Hi!

 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.

Agree

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

Because I thought it was related to the ELF format (32/64). I also looked
at the bfd/cpu-d10v.c that uses ELF32 and 16-bit addresses. It also looked
to me that this was quite coherent: define the ELF format in 'elf_size_info'
and define the CPU addresses in 'bfd_arch_info'.


> Hmm, that's an interesting question.  Some uses of arch_size in BFD
> seem to decide alignment of pointers (in .got, .rela and other
> sections in bfd/elflink.c) but others seem to be based on elf32
> vs. elf64 (.stabsstr section in bfd/elf.c).  GDB doesn't seem to use
> arch_size beyond the one usage we are discussing.  I didn't check
> binutils.  I think it is possible that bfd/elflink.c should be
> referring to bfd_arch_bits_per_address.
> 

I've not looked at that because I don't need dynamic/shared libs.

> 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).
> 
> Or to put it another way, specifically what went wrong on the 68HC11
> if you didn't change dwarf2read.c?  If it was just the "Dwarf Error:
> bad address size" error, what happens if you just comment out that
> check?

As far as I'm concerned, nothing.

	Stephane

-----------------------------------------------------------------------
         Home                               Office
E-mail: stcarrez@worldnet.fr               Stephane.Carrez@sun.com
WWW:    http://home.worldnet.fr/stcarrez   http://www.sun.com
Mail:   17, rue Foucher Lepelletier        6, avenue Gustave Eiffel
        92130 Issy Les Moulineaux          78182 Saint Quentin en Yvelines
        France