This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: RFA: print addresses that are longer than pointers, take two
Jim Blandy wrote:
>
> > > I recently made changes which allow GDB to handle architectures on
> > > which addresses are larger than pointers. However, the code which
> > > Peter Schauer added to printcmd.c to handle unwanted sign extension
> > > assumes that addresses and pointers are the same size.
> > >
> > > As it turns out, this masking is unnecessary when the value being
> > > printed is a genuine pointer; the sign extension won't occur, and the
> > > masking is unneeded.
> >
> > There is an important question here. How should GDB internally
> > represent an address obtained from C pointer values in memory when
> > TARGET_PTR_BIT (ie C pointer) < ``TARGET_CORE_ADDR_BIT''? Should it
> > sign extend it (as some architectures do) or not as others do.
>
> Here's my proposal:
>
> On all architectures, a CORE_ADDR is a byte address. CORE_ADDR must
> be large enough to assign a distinct address to every byte on the
> system --- even for machines with separate code and data spaces, word
> addressing, etc. Otherwise, it's pretty hard to figure out what
> read_memory should do. :)
Good.
Now consider a mips32 program (in elf32) running on a mips64 target
(another would be sparc32/sparc64). ADDRESS_TO_POINTER et.al. would
handle the translation required by ``void* <=> CORE_ADDR''. However,
what about the address information contained in the symtab and debug
sections. Wouldn't that also need to be converted to a cannonical form?
Digging through recent history, the change:
bfd/ChangeLog:
1999-11-17 Richard Henderson <rth@cygnus.com>
* elf-bfd.h (struct elf_backend_data): Reorder collect and
type_change_ok; add sign_extend_vma.
* elf32-mips.c (elf_backend_sign_extend_vma): Define.
* elfcode.h (elf_swap_symbol_in): Mind be->sign_extend_vma.
(elf_swap_shdr_in, elf_swap_phdr_in): Likewise.
* elfxx-target.h (elf_backend_sign_extend_vma): Default.
(elfNN_bed): Follow struture changes.
would have fixed the symtab values returned by BFD to gdb in the
mips32<->mips64 case. However, is there anything in GDB that ensures
the same behavour? Should GDB honor that flag when reading in debug
information (or say query the arch vector).
Andrew