Re: (patch) hpjyg22: misc. 32x64 and minor changes

[Andrew Cagney <ac131313 at cygnus dot 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