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

[Andrew Cagney <ac131313 at cygnus dot com>]

Stephane Carrez wrote:
> 
> Hi!
> 
> Andrew Cagney wrote:
> >
> > As for the change:
> >
> > > -  address_significant_size = get_elf_backend_data (abfd)->s->arch_size / 8;
> > > +  address_significant_size = bfd_arch_bits_per_address (abfd) / 8;
> >
> > I'm not so sure.  Does bfd_arch_bits_per_address() return 16 while the
> > elf data arch_size indicate something else (elf32 vs elf16?)
> >
> > I've attatched some references to when a similar problem was discussed
> > for a 64 bit target with 32 bit ELF binaries.
> >
> > Jim?
> >
> >         Andrew
> >
> > http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00267.html
> > http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00263.html
> >
> Yes
> 
> It returns the value held by the cpu-* bfd_arch_info_type structure:
> 
>   return abfd->arch_info->bits_per_address;
> 
> So, it's not related to the ELF format but really concerns the CPU address.
> The mips architecture is able to return either 32 or 64 depending on
> the CPU flavor.
> 
> From: Andrew Cagney <ac131313 at cygnus dot com>:
> > Is there a way of determining if an object file is 32 or 64 bit?  (eg
> > elf32/elf64, aout32 vs aout64).
> > Perhaphs bfd_arch_bits_per_address(ABFD) is correct?
> I think it's not correct but you should rather do:
> 
>         get_elf_backend_data (abfd)->s->arch_size
> 
> elf16 is not a good idea. I think we must not mix the size of cpu
> address with the format of ELF files. The ELF file can be larger than
> 64K and we might need indexes larger than 16-bit.

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.

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

	Andrew