From: Andrew Cagney <ac131313@ges.redhat.com>
To: Kevin Buettner <kevinb@redhat.com>, fnf@intrinsity.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] Another 64 bit CORE_ADDR & 32 bit target address printing botch
Date: Mon, 09 Sep 2002 12:36:00 -0000 [thread overview]
Message-ID: <3D7CF826.5020508@ges.redhat.com> (raw)
In-Reply-To: <1020909162819.ZM14375@localhost.localdomain>
> 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
prev parent reply other threads:[~2002-09-09 19:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-07 21:34 Fred Fish
2002-09-09 9:28 ` Kevin Buettner
2002-09-09 12:36 ` Andrew Cagney [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3D7CF826.5020508@ges.redhat.com \
--to=ac131313@ges.redhat.com \
--cc=fnf@intrinsity.com \
--cc=gdb-patches@sources.redhat.com \
--cc=kevinb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox