This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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



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


s->arch_size is not an especially meaningful field.  It exists only to
indicate whether you've got an ELF32 or ELF64 format file.

I think inventing a new ELF16 file format is a bad idea.  There are a
zillion things to take into account.  It's much simpler to just use
ELF32, and only link things into the lower 64k, which is what
we've done with other 16-bit processors in the past.

If you want to know the actual processor address size, there's a
different BFD field whose job is to provide that information.  That's
bfd_arch_bits_per_address, which Stephane suggested we use instead.

In general, the change that has dwarf2read checking the ELF backend
data has just been a pain from day one.  I remember fixing related
dependency problems, people on the binutils list saying "This looks
really wrong," and so on.  GDB shouldn't be using internal BFD
headers, and consulting internal ELF BFD data structures.

I also buy Jim Kingdon's argument that it shouldn't be necessary to
mask off the upper bits.  The data in the ELF file should be correct.

I'm going to revert the change which introduced
address_significant_size in the first place.  If this causes problems,
then we'll fix the bug correctly.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]