This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: (patch) hpjyg22: misc. 32x64 and minor changes
- To: Jimmy Guo <guo at cup dot hp dot com>
- Subject: Re: (patch) hpjyg22: misc. 32x64 and minor changes
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Mon, 06 Dec 1999 21:51:22 +1100
- CC: gdb-patches at sourceware dot cygnus dot com
- Organization: Cygnus Solutions
- References: <Pine.LNX.4.10.9911161159190.21892-100000@hpcll168.cup.hp.com>
Jimmy Guo wrote:
>
> >> ! printf_unfiltered ("%-12s",
> >> ! longest_local_hex_string_custom ((LONGEST) LM_ADDR (so),
> >> ! "08l"));
> >> ! printf_unfiltered ("%-12s",
> >> ! longest_local_hex_string_custom ((LONGEST) so->lmend,
> >> ! "08l"));
> >> printf_unfiltered ("%-12s", so->symbols_loaded ? "Yes" : "No");
> >> printf_unfiltered ("%s\n", so->so_name);
> >> }
> >
> >FYI, I'm not sure about this. Hardwiring ``08l'' looks dangerous.
>
> Actually longest_local_hex_string_custom makes use of the width argument
> ("08l" here) only when PRINTF_HAS_LONG_LONG is not defined (i.e. 32bit
> -- safe assumption??? what about 64bit long?). This is in par with the
> original ifdef logic in the code to pass "08l" for 32bit.
>
> >Perhaps paddr() should be used - that returns a string based on
> >TARGET_PTR_BIT. Hmm, here thougy, you're manipulating values from the
> >ELF object file format )??). Perhaphs something object-file related is
> >needed? Also, there are at least systems with elf32 object files but
> >TARGET_PTR_BIT=64.
> >
> >Hmm, to step back, I'm not sure what the problem that has occured is.
> >Could you please expand a little.
>
> >From the discussions so far, it appears that some consensus is due
> regarding the 32x64 problem dealing with various situations where this
> is needed. There has been 32x64 fixes in the Cygnus snapshots using
> paddr family of implementations. Since you are much familiar with the
> problem on hand and GDB, I'm all ears as to the best practice to be
> adopted here.
[I think I forgot to reply to this :-( ]
Since these are addresses being extracted from the symbol file there are
currently two possible mechanisms for printing them:
o sprintf_vma()
Found in the BFD library.
This does not adjust for the size of
the object file address (32/64) which
can result in bad user experiences.
(fprint_vma() isn't much use as GDB
writes to a ``struct gdb_file'' stream.)
o paddr ()
This uses the target ISA address which can
(very rarely be different to the object file
address). It does at least handle most
32/64 bit ISA issues!
( Don't personally like how paddr() was
implemented but then, at least it works :-)
While they are both wrong, paddr() might be argued is slightly less
wrong :-)
In line with paddr() available for printing an ISA address, I think that
there should be a mechanism for printing the raw symbol file address
provided by BFD. Off hand I can think of:
o p_bfd_vma()
Just like the existing paddr().
o print_bfd_vma (addr, stream)
thoughts?
Andrew