[PATCH] Fix ptype.exp fail in MIPS

[PATCH] Fix ptype.exp fail in MIPS

[Hui Zhu]

ptype $pc
type = int32_t
(gdb) FAIL: gdb.base/ptype.exp: ptype $pc
This is because the $pc register in MIPS is set to int but not code_ptr.
And according to the discussion in
https://sourceware.org/ml/gdb/2013-06/msg00020.html, the type cannot be
changed.
So I make a patch for ptype.exp.

Thanks,
Hui

2014-05-13  Hui Zhu  <hui@codesourcery.com>

	* gdb.base/ptype.exp: Add special "ptype $pc" test for MIPS.

Index: gdb-trunk/gdb/testsuite/gdb.base/ptype.exp
===================================================================
--- gdb-trunk.orig/gdb/testsuite/gdb.base/ptype.exp	2014-05-12 
19:55:30.759020736 -0700
+++ gdb-trunk/gdb/testsuite/gdb.base/ptype.exp	2014-05-12 
20:42:18.057516141 -0700
@@ -631,5 +631,9 @@
    set timeout $prev_timeout

    # Test ptype of user register
-  gdb_test "ptype \$pc" "void \\(\\*\\)\\(\\)" "ptype \$pc"
+  if { ![istarget "mips*-*-*"] } then {
+    gdb_test "ptype \$pc" "void \\(\\*\\)\\(\\)" "ptype \$pc"
+  } else {
+    gdb_test "ptype \$pc" "int.*|long.*" "ptype \$pc"
+  }
  }

Re: [PATCH] Fix ptype.exp fail in MIPS

[Tom Tromey]

>>>>> "Hui" == Hui Zhu <hui_zhu@mentor.com> writes:

Hui> 2014-05-13  Hui Zhu  <hui@codesourcery.com>

Hui> 	* gdb.base/ptype.exp: Add special "ptype $pc" test for MIPS.

Ok.

Tom

Re: [PATCH] Fix ptype.exp fail in MIPS

[Pedro Alves]

On 05/13/2014 05:09 AM, Hui Zhu wrote:
> ptype $pc
> type = int32_t
> (gdb) FAIL: gdb.base/ptype.exp: ptype $pc
> This is because the $pc register in MIPS is set to int but not code_ptr.
> And according to the discussion in
> https://sourceware.org/ml/gdb/2013-06/msg00020.html, the type cannot be
> changed.

Hmm, that's not what I get from this branch of the discussion:

 https://sourceware.org/ml/gdb/2013-06/msg00021.html

-- 
Pedro Alves

Re: [PATCH] Fix ptype.exp fail in MIPS

[Hui Zhu]

On Fri, May 16, 2014 at 1:53 AM, Pedro Alves <palves@redhat.com> wrote:
> On 05/13/2014 05:09 AM, Hui Zhu wrote:
>> ptype $pc
>> type = int32_t
>> (gdb) FAIL: gdb.base/ptype.exp: ptype $pc
>> This is because the $pc register in MIPS is set to int but not code_ptr.
>> And according to the discussion in
>> https://sourceware.org/ml/gdb/2013-06/msg00020.html, the type cannot be
>> changed.
>
> Hmm, that's not what I get from this branch of the discussion:
>
>  https://sourceware.org/ml/gdb/2013-06/msg00021.html
>
> --

https://sourceware.org/ml/gdb/2013-06/msg00032.html
Do you think add ptr64 or $_xx is OK for you to handle this issue?

Thanks,
Hui

> Pedro Alves
>

Re: [PATCH] Fix ptype.exp fail in MIPS

[Doug Evans]

On Fri, May 16, 2014 at 12:40 AM, Hui Zhu <teawater@gmail.com> wrote:
> On Fri, May 16, 2014 at 1:53 AM, Pedro Alves <palves@redhat.com> wrote:
>> On 05/13/2014 05:09 AM, Hui Zhu wrote:
>>> ptype $pc
>>> type = int32_t
>>> (gdb) FAIL: gdb.base/ptype.exp: ptype $pc
>>> This is because the $pc register in MIPS is set to int but not code_ptr.
>>> And according to the discussion in
>>> https://sourceware.org/ml/gdb/2013-06/msg00020.html, the type cannot be
>>> changed.
>>
>> Hmm, that's not what I get from this branch of the discussion:
>>
>>  https://sourceware.org/ml/gdb/2013-06/msg00021.html
>>
>> --
>
> https://sourceware.org/ml/gdb/2013-06/msg00032.html
> Do you think add ptr64 or $_xx is OK for you to handle this issue?

IIUC it's not just adding $_xx but changing the type of $pc so that
ptype.exp will pass as is.
Is that correct?

Re: [PATCH] Fix ptype.exp fail in MIPS

[Hui Zhu]

On Mon, May 19, 2014 at 10:51 PM, Doug Evans <xdje42@gmail.com> wrote:
> On Fri, May 16, 2014 at 12:40 AM, Hui Zhu <teawater@gmail.com> wrote:
>> On Fri, May 16, 2014 at 1:53 AM, Pedro Alves <palves@redhat.com> wrote:
>>> On 05/13/2014 05:09 AM, Hui Zhu wrote:
>>>> ptype $pc
>>>> type = int32_t
>>>> (gdb) FAIL: gdb.base/ptype.exp: ptype $pc
>>>> This is because the $pc register in MIPS is set to int but not code_ptr.
>>>> And according to the discussion in
>>>> https://sourceware.org/ml/gdb/2013-06/msg00020.html, the type cannot be
>>>> changed.
>>>
>>> Hmm, that's not what I get from this branch of the discussion:
>>>
>>>  https://sourceware.org/ml/gdb/2013-06/msg00021.html
>>>
>>> --
>>
>> https://sourceware.org/ml/gdb/2013-06/msg00032.html
>> Do you think add ptr64 or $_xx is OK for you to handle this issue?
>
> IIUC it's not just adding $_xx but changing the type of $pc so that
> ptype.exp will pass as is.
> Is that correct?

I am not sure.  But looks we cannot do that in MIPS.
https://sourceware.org/ml/gdb/2013-06/msg00028.html
Maciej introduced in this part.

Thanks,
Hui

Re: [PATCH] Fix ptype.exp fail in MIPS

[Pedro Alves]

On 05/16/2014 08:40 AM, Hui Zhu wrote:
> On Fri, May 16, 2014 at 1:53 AM, Pedro Alves <palves@redhat.com> wrote:
>> On 05/13/2014 05:09 AM, Hui Zhu wrote:
>>> ptype $pc
>>> type = int32_t
>>> (gdb) FAIL: gdb.base/ptype.exp: ptype $pc
>>> This is because the $pc register in MIPS is set to int but not code_ptr.
>>> And according to the discussion in
>>> https://sourceware.org/ml/gdb/2013-06/msg00020.html, the type cannot be
>>> changed.
>>
>> Hmm, that's not what I get from this branch of the discussion:
>>
>>  https://sourceware.org/ml/gdb/2013-06/msg00021.html
>>
>> --
> 
> https://sourceware.org/ml/gdb/2013-06/msg00032.html

That was an alternative proposal, but nobody replied saying
it was a great idea, so I don't know.  The main disadvantage
is that the user would have to know about these different
registers, which may be confusing and obscure.

> Do you think add ptr64 or $_xx is OK for you to handle this issue?

I'm leaning torwards ptr64.  Anyone see a reason why that wouldn't work?

That was also sort of agreed upon by both Mark and Maciej at:

 https://sourceware.org/ml/gdb/2013-06/msg00029.html

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

But of course that was a while ago and they might have changed
their minds since.

-- 
Pedro Alves

Re: [PATCH] Fix ptype.exp fail in MIPS

[Pedro Alves]

On 05/19/2014 03:51 PM, Doug Evans wrote:
> On Fri, May 16, 2014 at 12:40 AM, Hui Zhu <teawater@gmail.com> wrote:
>> On Fri, May 16, 2014 at 1:53 AM, Pedro Alves <palves@redhat.com> wrote:
>>> On 05/13/2014 05:09 AM, Hui Zhu wrote:
>>>> ptype $pc
>>>> type = int32_t
>>>> (gdb) FAIL: gdb.base/ptype.exp: ptype $pc
>>>> This is because the $pc register in MIPS is set to int but not code_ptr.
>>>> And according to the discussion in
>>>> https://sourceware.org/ml/gdb/2013-06/msg00020.html, the type cannot be
>>>> changed.
>>>
>>> Hmm, that's not what I get from this branch of the discussion:
>>>
>>>  https://sourceware.org/ml/gdb/2013-06/msg00021.html
>>>
>>> --
>>
>> https://sourceware.org/ml/gdb/2013-06/msg00032.html
>> Do you think add ptr64 or $_xx is OK for you to handle this issue?
> 
> IIUC it's not just adding $_xx but changing the type of $pc so that
> ptype.exp will pass as is.
> Is that correct?

Yeah.  As listed at the bottom of that url, $pc would be
changed to be the ABI function pointer width (32-bit pointer),
as a pseudo-register, and $_pc/$rNN would be mapped to the
machine's full 64-bit contents, as an integer.

I'm not certain this is a good idea of not in terms of user
interface.  I know _I_ wouldn't be confused, and I know I have
been confused by $sp/$esp/$rsp on x86 before ($sp is not really
what one would expect if one doesn't know about GDB's special
magic stack pointer register), but I'm not really representative
of a regular gdb user.

-- 
Pedro Alves

Re: [PATCH] Fix ptype.exp fail in MIPS

[Maciej W. Rozycki]

On Tue, 27 May 2014, Pedro Alves wrote:

> > https://sourceware.org/ml/gdb/2013-06/msg00032.html
> 
> That was an alternative proposal, but nobody replied saying
> it was a great idea, so I don't know.  The main disadvantage
> is that the user would have to know about these different
> registers, which may be confusing and obscure.
> 
> > Do you think add ptr64 or $_xx is OK for you to handle this issue?
> 
> I'm leaning torwards ptr64.  Anyone see a reason why that wouldn't work?
> 
> That was also sort of agreed upon by both Mark and Maciej at:
> 
>  https://sourceware.org/ml/gdb/2013-06/msg00029.html
> 
> "
> >  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.
> "
> 
> But of course that was a while ago and they might have changed
> their minds since.

 I don't have a clear preference towards either proposal.  Ideally we'd 
move away from using any names for magic registers that clash with actual 
hardware register names on some or all targets.  But it would have been 
good ~30 years ago when GDB was starting.  Nowadays I think too many users 
are used to what we use and a lot of effort invested would break.  Maybe 
that's actually an argument in favour of your solution.

  Maciej