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


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

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

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.

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?

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