Re: [RFA] string_to_core_addr fix

[Andrew Cagney <ac131313@redhat.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.

Sigh, looks like it was private e-mail :-(

>> 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?

(not sure what `sometimes' was bound too)
A CORE_ADDR always contains an address converted to a canonical form. 
For the MIPS (32 or 64 bit), when GDB is debugging a 32 bit ABI, the 
CORE_ADDR will always contain a canonical value that has been created by 
sign-extending the 32 bit pointer or register value.

>>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?

(is core_addr_to_string_nz() used?)

Addresses are ment to be displayed using print_address_numeric() and 
similar.  A user specified value would be parsed with something like 
parse_and_eval_address().

On the other hand, string<->core_addr() is used as a way for Insight to 
create an internal address handle (for saving things like frames).  The 
user should not be able to access or manipulate such values directly.

> 
>> 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.

I know of several ongoing bugs:

- GDB forgetting to convert a pointer into a core_addr
- GDB/Insight incorrectly interchanging addresses and core_addr

> 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).

That code is definitly wrong.  The equality:
	core_addr == string_to_core_addr (paddr_nz (core_addr))
does NOT hold.

The code should either:

- use string <-> core_addr() and not let the user directly manipulate 
the values (insight could manipulate it though).

- Convert the CORE_ADDR back into an address, let the user manipulate 
the address, and then use parse_and_eval_address() to get the core_addr 
back.  Not sure how well this would go with harvard architectures though 
- for them, a simple address may not be sufficient for re-constructing 
the CORE_ADDR.
	
Any way, the patch should be reverted.

Andrew