Re: [RFA] string_to_core_addr fix

["Martin M. Hunt" <hunt at redhat dot com>]

On Mon, 2002-10-21 at 13:06, Andrew Cagney wrote:

> Insight parse_and_eval_address() was simply bogus.  See the thread 
> around the original introduction of these functions. 

I looked.  All I found was something about parse_and_eval_address()
being broken for harvard arch.

> A short summary is 
> that parse_and_eval_address() does conversions like you describe and 
> none are needed.  Instead functions that parse in, write out, raw 
> CORE_ADDR values are needed.

I believe we have target addrs and CORE_ADDRs, where CORE_ADDRs are
sometimes target addrs sign-extended to 64-bits.  Is that not right?

If the user types something like "x/10i 0xA0000000" on a Mips
architecture, is the address not sign-extended to a 64-bit CORE_ADDR?

>From memory, you print out a target addr by using paddr_nz.  If you
wanted to print a CORE_ADDR you would use core_addr_to_string_nz. You
can read in a CORE_ADDR with string_to_core_addr. So how do you read in
a target addr and have it converted to a CORE_ADDR?

> I believe that this change is wrong and should be reverted.

By your definition of string_to_core_addr below, I agree.  However, this
bug has been here a long time and I would like some agreement on how it
should properly be fixed.

The bug is simply that Insight gets CORE_ADDRs for any symbol lookup. 
It must convert them to strings and uses paddr_nz.  Then the user does
something with that address and Insight converts that address string
back into a CORE_ADDR incorrectly (it doesn't sign-extend to 64-bits,
therefore my patch).
 
> Per above, string_to_core_addr() and core_addr_to_string() scan/print 
> raw CORE_ADDR values.  If there is some sort of conversion problem going 
> on then this  indicates that something isn't writing out / reading a raw 
> CORE_ADDR value correctly (or some code is trying to use the function 
> incorrectly).
> 
> Andrew
> 
>