Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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



      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