Re: Assuming types for PC

> Date: Mon, 10 Jun 2013 16:33:56 +0200
> From: Luis Machado <[email protected]>
> 
> On 06/10/2013 04:31 PM, Mark Kettenis wrote:
> >> Date: Mon, 10 Jun 2013 16:19:22 +0200
> >> From: Luis Machado <[email protected]>
> >>
> >> 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".