This is the mail archive of the
mailing list for the GDB project.
Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
- From: Stephane Carrez <Stephane dot Carrez at worldnet dot fr>
- Date: Sat, 04 Mar 2000 10:39:37 +0100
- CC: gdb-patches at sourceware dot cygnus dot com, Jim Blandy <jimb at cygnus dot com>
- References: <38B2F3D3.54CF0AF0@worldnet.fr> <38BB5463.D6E5B75C@cygnus.com>
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.
It returns the value held by the cpu-* bfd_arch_info_type structure:
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:
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.
E-mail: email@example.com 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