* [RFC] Another 64 bit CORE_ADDR & 32 bit target address printing botch
@ 2002-09-07 21:34 Fred Fish
2002-09-09 9:28 ` Kevin Buettner
0 siblings, 1 reply; 3+ messages in thread
From: Fred Fish @ 2002-09-07 21:34 UTC (permalink / raw)
To: gdb-patches; +Cc: fnf
I found another place where 32 bit addresses with the MSB set are printed
as 0xffffffffxxxxxxxx. I hacked around the problem with this patch,
but it might not be the best place to do it. Any better ideas?
-Fred
Index: ui-out.c
===================================================================
RCS file: /mips/newtools/fsf/gdb/gdb/ui-out.c,v
retrieving revision 1.1.1.3
diff -c -r1.1.1.3 ui-out.c
*** ui-out.c 2002/08/31 02:49:14 1.1.1.3
--- ui-out.c 2002/09/08 04:29:28
***************
*** 491,506 ****
CORE_ADDR address)
{
char addstr[20];
/* FIXME: cagney/2002-05-03: Need local_address_string() function
that returns the language localized string formatted to a width
based on TARGET_ADDR_BIT. */
/* print_address_numeric (address, 1, local_stream); */
if (TARGET_ADDR_BIT <= 32)
! strcpy (addstr, local_hex_string_custom (address, "08l"));
else
! strcpy (addstr, local_hex_string_custom (address, "016l"));
!
ui_out_field_string (uiout, fldname, addstr);
}
--- 491,510 ----
CORE_ADDR address)
{
char addstr[20];
+ char *fmt;
/* FIXME: cagney/2002-05-03: Need local_address_string() function
that returns the language localized string formatted to a width
based on TARGET_ADDR_BIT. */
/* print_address_numeric (address, 1, local_stream); */
+
if (TARGET_ADDR_BIT <= 32)
! fmt = "08l";
else
! fmt = "016l";
! if (TARGET_ADDR_BIT < (sizeof (CORE_ADDR) * HOST_CHAR_BIT))
! address &= ((CORE_ADDR) 1 << TARGET_ADDR_BIT) - 1;
! strcpy (addstr, local_hex_string_custom (address, fmt));
ui_out_field_string (uiout, fldname, addstr);
}
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC] Another 64 bit CORE_ADDR & 32 bit target address printing botch
2002-09-07 21:34 [RFC] Another 64 bit CORE_ADDR & 32 bit target address printing botch Fred Fish
@ 2002-09-09 9:28 ` Kevin Buettner
2002-09-09 12:36 ` Andrew Cagney
0 siblings, 1 reply; 3+ messages in thread
From: Kevin Buettner @ 2002-09-09 9:28 UTC (permalink / raw)
To: fnf, gdb-patches
On Sep 7, 11:33pm, Fred Fish wrote:
> I found another place where 32 bit addresses with the MSB set are printed
> as 0xffffffffxxxxxxxx. I hacked around the problem with this patch,
> but it might not be the best place to do it. Any better ideas?
Was this on MIPS? Aren't these addresses supposed to be sign extended on
MIPS?
In any event, if the address stored in the CORE_ADDR is incorrect, I think
it'd be better to fix it at the point where it's being stored incorrectly.
Kevin
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC] Another 64 bit CORE_ADDR & 32 bit target address printing botch
2002-09-09 9:28 ` Kevin Buettner
@ 2002-09-09 12:36 ` Andrew Cagney
0 siblings, 0 replies; 3+ messages in thread
From: Andrew Cagney @ 2002-09-09 12:36 UTC (permalink / raw)
To: Kevin Buettner, fnf; +Cc: gdb-patches
> On Sep 7, 11:33pm, Fred Fish wrote:
>
>
>> I found another place where 32 bit addresses with the MSB set are printed
>> as 0xffffffffxxxxxxxx. I hacked around the problem with this patch,
>> but it might not be the best place to do it. Any better ideas?
>
>
> Was this on MIPS? Aren't these addresses supposed to be sign extended on
> MIPS?
Yep, the value is definitly correct.
> In any event, if the address stored in the CORE_ADDR is incorrect, I think
> it'd be better to fix it at the point where it's being stored incorrectly.
The problem isn't with the sign extension. Rather, its with the
function proper. The comment:
> /* FIXME: cagney/2002-05-03: Need local_address_string() function
> that returns the language localized string formatted to a width
> based on TARGET_ADDR_BIT. */
drops a vague hit as to the problem. The function is ment to be
printing an address (of size TARGET_ADDR_BIT) and not a CORE_ADDR (of
size sizeof (CORE_ADDR) * HOST_CHAR_BIT). The function name
(..._core_addr), unfortunatly really confuses this.
I'm just left wondering if the code should also check for truncation.
That CORE_ADDR -> address -> CORE_ADDR doesn't loose information. Hmm,
grub grub:
/* Print address ADDR on STREAM. USE_LOCAL means the same thing as for
print_longest. */
void
print_address_numeric (CORE_ADDR addr, int use_local, struct ui_file
*stream)
{
/* Truncate address to the size of a target address, avoiding shifts
larger or equal than the width of a CORE_ADDR. The local
variable ADDR_BIT stops the compiler reporting a shift overflow
when it won't occur. */
/* NOTE: This assumes that the significant address information is
kept in the least significant bits of ADDR - the upper bits were
either zero or sign extended. Should ADDRESS_TO_POINTER() or
some ADDRESS_TO_PRINTABLE() be used to do the conversion? */
int addr_bit = TARGET_ADDR_BIT;
if (addr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT))
addr &= ((CORE_ADDR) 1 << addr_bit) - 1;
print_longest (stream, 'x', use_local, (ULONGEST) addr);
}
So, Fred, yes ok but steal the above code and comment.
Andrew
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-09-09 19:36 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-09-07 21:34 [RFC] Another 64 bit CORE_ADDR & 32 bit target address printing botch Fred Fish
2002-09-09 9:28 ` Kevin Buettner
2002-09-09 12:36 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox