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: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: (patch) hpjyg22: misc. 32x64 and minor changes
- From: Jimmy Guo <guo at cup dot hp dot com>
- Date: Tue, 16 Nov 1999 12:15:03 -0800 (PST)
- cc: gdb-patches at sourceware dot cygnus dot com
>> ! 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.
Thanks!
- Jimmy Guo, guo@cup.hp.com