Re: [RFA] string_to_core_addr fix

Andrew Cagney
2002-10-21T20:06:27Z

> On Oct 10, 9:29pm, Martin M. Hunt wrote:
>
>
>> For years we used parse_and_eval_address() in Insight until earlier this year
>> when those calls were replaced with string_to_core_addr(), breaking all mips
>> targets. parse_and_eval_address() internally calls INTEGER_TO_ADDRESS() so I
>> probably should use that. In fact I decided to just do what
>> parse_and_eval_address() did but apparently submitted the wrong version.

Insight parse_and_eval_address() was simply bogus. See the thread
around the original introduction of these functions. 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.

Switching to string_to_core_addr() and core_addr_to_string() flushed out
a heap of address conversion problems for the d10v, and I beleive, the MIPS.

>> Revised patch attached.
>>
>> Index: utils.c
>> ===================================================================
>> RCS file: /cvs/src/src/gdb/utils.c,v
>> retrieving revision 1.80
>> diff -u -p -r1.80 utils.c
>> --- utils.c 20 Sep 2002 00:24:01 -0000 1.80
>> +++ utils.c 11 Oct 2002 04:29:51 -0000
>> @@ -2649,6 +2649,8 @@ string_to_core_addr (const char *my_stri
>> internal_error (__FILE__, __LINE__, "invalid decimal");
>> }
>> }
>> + if (INTEGER_TO_ADDRESS_P ())
>> + addr = INTEGER_TO_ADDRESS (builtin_type_void_data_ptr, &addr);
>> return addr;
>> }
>
>
> Okay, this version looks reasonable. (Approved.) Make sure you
> update the ChangeLog entry to match.

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

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