Re: Assuming types for PC

Mark Kettenis
2013-06-10T15:04:59Z

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