Re: Assuming types for PC

[Luis Machado <lgustavo@codesourcery.com>]

On 06/10/2013 05:04 PM, Mark Kettenis wrote:
>> Date: Mon, 10 Jun 2013 16:33:56 +0200
>> From: Luis Machado <lgustavo@codesourcery.com>
>>
>> On 06/10/2013 04:31 PM, Mark Kettenis wrote:
>>>> Date: Mon, 10 Jun 2013 16:19:22 +0200
>>>> From: Luis Machado <lgustavo@codesourcery.com>
>>>>
>>>> Hi,
>>>>
>>>> I see gdb.base/ptype.exp assuming PC needs to be of type void (*)().
>>>>
>>>>      # Test ptype of user register
>>>>      gdb_test "ptype \$pc" "void \\(\\*\\)\\(\\)" "ptype \$pc"
>>>>
>>>> Is there any reason we should assume that? Some targets use "long long"
>>>> or "int32_t" for PC.
>>>
>>> I consider that to be a bug.  Fixing that bug turned out to be
>>> somewhat difficult on some architectures that have a 32-bit/64-bit
>>> identity crisis; see the x32 discussions from last year.
>>
>> Architectures are free to deal with the types of their PC's as they
>> please. Some keep the standard while others don't. I don't have a strong
>> opinion here, but i wouldn't call this a bug immediately.
>
> When the PC type is "code_ptr", GDB does some useful pretty printing
> that it doesn't do if it is a simple integer type.  Like printing the
> function name thet the PC points to.  I think GDB should do that for
> all architectures.
>
>>>> If PC should not have a fixed type, i think it would be best to remove
>>>> this check.
>>>
>>> Please don't.
>>
>> Is there a more elaborate reasoning for not removing this check?
>
> It serves a s a reminder that there are still issues to fix for some
> of the architectures.  Perhaps we should add a KFAIL for architectures
> that have the 32-bit/64-bit identity crisis I mentioned.  But other
> architectures should just change the PC type to "code_ptr".
>

Thanks. That makes sense. Well, oddball architectures may just have to 
ignore this, or fix it some other way.

Regards,
Luis