Assuming types for PC

Assuming types for PC

[Luis Machado]

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.

If PC should not have a fixed type, i think it would be best to remove 
this check.

Re: Assuming types for PC

[Mark Kettenis]

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

> If PC should not have a fixed type, i think it would be best to remove 
> this check.

Please don't.

Re: Assuming types for PC

[Luis Machado]

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.

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

Re: Assuming types for PC

[Joel Brobecker]

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

Here is a URL to the original discussion. DanielJ mention that we might
want to loosen up the check, but then added something that confirms
Mark's preference:

http://www.sourceware.org/ml/gdb-patches/2008-01/msg00699.html
| Might want to loosen the expected type; I don't think every platform
| returns a function type for PC.
|
| Then again, might not want to - everyone should do so :-)

So, I'm guessing that without a compelling reason to change it,
it should stay that way...

-- 
Joel

Re: Assuming types for PC

[Luis Machado]

On 06/10/2013 04:45 PM, Joel Brobecker wrote:
>> 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.
>>
>>>
>>>> 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?
>
> Here is a URL to the original discussion. DanielJ mention that we might
> want to loosen up the check, but then added something that confirms
> Mark's preference:
>
> http://www.sourceware.org/ml/gdb-patches/2008-01/msg00699.html
> | Might want to loosen the expected type; I don't think every platform
> | returns a function type for PC.
> |
> | Then again, might not want to - everyone should do so :-)
>
> So, I'm guessing that without a compelling reason to change it,
> it should stay that way...
>

Right. I did some archaeology and ended up at that commit, aimed at 
testing for an internal error fix rather than the correct type of PC.

I didn't find the reasoning particularly clear. Then again, i'm just 
asking to be sure. :-)

Re: Assuming types for PC

[Joel Brobecker]

> Right. I did some archaeology and ended up at that commit, aimed at
> testing for an internal error fix rather than the correct type of
> PC.

Ah, ok :).

> I didn't find the reasoning particularly clear. Then again, i'm just
> asking to be sure. :-)

Maybe another way of saying this would be "it should, unless proven
otherwise". In your case, it sounds like you are saying "it might",
or perhaps "some platforms don't", to which Mark is replying "show
me" (backed by the architecture manuals) :-) :-) :-).

-- 
Joel

Re: Assuming types for PC

[Mark Kettenis]

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

Re: Assuming types for PC

[Luis Machado]

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

Re: Assuming types for PC

[Maciej W. Rozycki]

On Mon, 10 Jun 2013, Mark Kettenis wrote:

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

 That's not going to work for cases like MIPS n32 (the original cause of 
the failure) that is a 64-bit ILP32 ABI.  There the PC like all the 
general registers is 64-bit wide and the pointer type is 32-bit, which is 
narrower than a register.  This is solved by using the "long long" type as 
the register type (that type is specified by the ABI to occupy a single 
hardware register; also stack frames use slots of this size to store 
registers).

 I think it is important to let the user access the full width of the PC 
both for writes and -- more importantly -- for reads (as in: why did my 
program crash, did it jump to an odd place?), as this lets the user do 
with GDB what hardware permits.  There is nothing in hardware that 
prevents one from writing an out-of-valid ABI address space value to the 
PC at a program's runtime (neither on Linux nor on bare iron) when 
executing an n32 program.  I think GDB should not stand in a user's way 
and should allow the same to be done via ptrace(2) or RSP.

 Overall I think the test is too strict.  If you think the use of "long 
long" is unfortunate for the PC, then an artificial type might be created 
internally within GDB specifically for the PC, similarly to what we do 
e.g. for IEEE 754 data types and floating-point registers in some cases.

 Joel, I hope this serves your:

> Maybe another way of saying this would be "it should, unless proven 
> otherwise". In your case, it sounds like you are saying "it might", or 
> perhaps "some platforms don't", to which Mark is replying "show me" 
> (backed by the architecture manuals) :-) :-) :-).

request for a justification...

 ... ah, you've asked for a manual too -- here's one then:

http://techpubs.sgi.com/library/manuals/2000/007-2816-004/pdf/007-2816-004.pdf

;)

  Maciej

Re: Assuming types for PC

[Mark Kettenis]

> Date: Mon, 10 Jun 2013 19:04:08 +0100
> From: "Maciej W. Rozycki" <macro@codesourcery.com>
> 
> On Mon, 10 Jun 2013, Mark Kettenis wrote:
> 
> > > >> 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".
> 
>  That's not going to work for cases like MIPS n32 (the original cause of 
> the failure) that is a 64-bit ILP32 ABI.  There the PC like all the 
> general registers is 64-bit wide and the pointer type is 32-bit, which is 
> narrower than a register.  This is solved by using the "long long" type as 
> the register type (that type is specified by the ABI to occupy a single 
> hardware register; also stack frames use slots of this size to store 
> registers).

Yes, MIPS n32 is one of those architectures with a 32-bit/64-bit
identity crisis ;).

>  I think it is important to let the user access the full width of the PC 
> both for writes and -- more importantly -- for reads (as in: why did my 
> program crash, did it jump to an odd place?), as this lets the user do 
> with GDB what hardware permits.  There is nothing in hardware that 
> prevents one from writing an out-of-valid ABI address space value to the 
> PC at a program's runtime (neither on Linux nor on bare iron) when 
> executing an n32 program.  I think GDB should not stand in a user's way 
> and should allow the same to be done via ptrace(2) or RSP.

Absolutely!

>  Overall I think the test is too strict.  If you think the use of "long 
> long" is unfortunate for the PC, then an artificial type might be created 
> internally within GDB specifically for the PC, similarly to what we do 
> e.g. for IEEE 754 data types and floating-point registers in some cases.

An artificial type like that probably is the way to go.

Re: Assuming types for PC

[Pedro Alves]

On 06/10/2013 07:44 PM, Mark Kettenis wrote:
>> Date: Mon, 10 Jun 2013 19:04:08 +0100
>> From: "Maciej W. Rozycki" <macro@codesourcery.com>
>>
>>  I think it is important to let the user access the full width of the PC 
>> both for writes and -- more importantly -- for reads (as in: why did my 
>> program crash, did it jump to an odd place?), as this lets the user do 
>> with GDB what hardware permits.  There is nothing in hardware that 
>> prevents one from writing an out-of-valid ABI address space value to the 
>> PC at a program's runtime (neither on Linux nor on bare iron) when 
>> executing an n32 program.  I think GDB should not stand in a user's way 
>> and should allow the same to be done via ptrace(2) or RSP.
> 
> Absolutely!

+1.  Hmm, it'd be nice to have this spelled out in the internals manual
(or the wiki?).  I while ago I pointed this out on a review of some
port.  Can't recall which, but in the end I let it go.  Maybe I should
have pushed back stronger.

>>  Overall I think the test is too strict.  If you think the use of "long 
>> long" is unfortunate for the PC, then an artificial type might be created 
>> internally within GDB specifically for the PC, similarly to what we do 
>> e.g. for IEEE 754 data types and floating-point registers in some cases.
> 
> An artificial type like that probably is the way to go.

I agree.  Something like the GDB equivalent of:

  typedef void * ptr64 __attribute ((mode(DI)));

(That worked last time I tried it on x32, probably works on MIPS too.)

-- 
Pedro Alves

Re: Assuming types for PC

[Pedro Alves]

On 06/11/2013 10:21 AM, Pedro Alves wrote:
>>>  Overall I think the test is too strict.  If you think the use of "long 
>>> long" is unfortunate for the PC, then an artificial type might be created 
>>> internally within GDB specifically for the PC, similarly to what we do 
>>> e.g. for IEEE 754 data types and floating-point registers in some cases.
>>
>> An artificial type like that probably is the way to go.
> 
> I agree.  Something like the GDB equivalent of:
> 
>   typedef void * ptr64 __attribute ((mode(DI)));
> 
> (That worked last time I tried it on x32, probably works on MIPS too.)
> 

BTW, this whole issue is really a special case of an ABI register name
colliding with a machine register name.  A similar example came up when GDB
was made to expose whole set of x86 general purpose registers.  Specifically
the $rsp/$rsp/$sp, where $sp (16-bit) collides with desire to use $sp
to refer to stack pointer.  An alternative idea I thrown out back then,
would be to always leave $pc/$sp/$fp as the ABI version of the registers,
and in case the machine has real registers by that name, expose those with
an alternative naming, like e.g., $_pc/$_sp/$_fp.  These would have the
machine's full width.

On i686, you'd get:
 32-bit pointer $pc, 16-bit integer $ip, 32-bit pointer $eip.
 32-bit pointer $sp, 16-bit integer $_sp, 32-bit pointer $esp.
 32-bit pointer $fp, 16-bit integer $bp, 32-bit pointer $ebp.

On x32, you'd get:
 32-bit pointer $pc, 16-bit integer $ip, 32-bit pointer $eip, 64-bit integer $rip.
 32-bit pointer $sp, 16-bit integer $_sp, 32-bit pointer $esp, 64-bit integer $rsp.
 32-bit pointer $fp, 16-bit integer $bp, 32-bit pointer $ebp, 64-bit integer $rbp.

On x86_64 (-m64), you'd get
 64-bit pointer $pc, 16-bit integer $ip, 32-bit integer $eip, 64-bit pointer $rip.
 64-bit pointer $sp, 16-bit integer $_sp, 32-bit integer $esp, 64-bit pointer $rsp.
 64-bit pointer $fp, 16-bit integer $bp, 32-bit integer $ebp, 64-bit pointer $rbp.

On MIPS n32, you'd get:
 32-bit pointer $pc, 64-bit integer $_pc/$rNN.
 32-bit pointer $sp, 64-bit integer $_sp/$rNN.
 32-bit pointer $fp, 64-bit integer $_fp/$rNN.

(the _ variants probably would be raw from any arch bit manipulation).

(I'm not really sure which solution I prefer.)

-- 
Pedro Alves