Re: RFA: print addresses that are longer than pointers, take two

[Andrew Cagney <ac131313 at cygnus dot com>]

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