prev_pc problem on ia64

prev_pc problem on ia64

[J. Johnston]

I am running into a problem on ia64 regarding performing a next
after an inferior function call or after using "return" from
a function.

What's occurring is that an inferior function call ends up setting
the static prev_pc value in infrun.c: stop_stepping().  When we
return to the gdb prompt prev_pc is not restored to its original
value.  A similar problem occurs when we return from a function
using the gdb return command.

On the ia64, there are extraneous line table entries that do not
increase the line number.  When we perform a next after the inferior
call, we step until the line number changes from the one set for
prev_pc.  Unfortunately, this only gets us part way through the line as
we run until the next line table entry.

For the x86, this problem does not crop up in the test case I am looking
at because there are none of these additional line table entries.  When
we perform a next, it finds the next line regardless of the fact that prev_pc is
not correctly set.

The following is an example of the line table entries I am talking about on
the ia64 (generated by readelf -wl).  I am using a recent gcc but this behavior
also occurs for gcc 2.96

   Special opcode 20: advance Address by 1 to 0x40000000000007e1 and Line by 1 to 31
   Special opcode 215: advance Address by 15 to 0x40000000000007f0 and Line by 0 to 31
   Special opcode 19: advance Address by 1 to 0x40000000000007f1 and Line by 0 to 31
   Special opcode 19: advance Address by 1 to 0x40000000000007f2 and Line by 0 to 31
   Special opcode 201: advance Address by 14 to 0x4000000000000800 and Line by 0 to 31
   Special opcode 20: advance Address by 1 to 0x4000000000000801 and Line by 1 to 32
   Special opcode 243: advance Address by 17 to 0x4000000000000812 and Line by 0 to 32
   Special opcode 201: advance Address by 14 to 0x4000000000000820 and Line by 0 to 32
   Special opcode 19: advance Address by 1 to 0x4000000000000821 and Line by 0 to 32
   Special opcode 19: advance Address by 1 to 0x4000000000000822 and Line by 0 to 32
   Special opcode 201: advance Address by 14 to 0x4000000000000830 and Line by 0 to 32
   Special opcode 19: advance Address by 1 to 0x4000000000000831 and Line by 0 to 32

Same function compiled for i686:

   Special opcode 76: advance Address by 5 to 0x804839e and Line by 1 to 31
   Special opcode 230: advance Address by 16 to 0x80483ae and Line by 1 to 32
   Special opcode 146: advance Address by 10 to 0x80483b8 and Line by 1 to 33
   Special opcode 160: advance Address by 11 to 0x80483c3 and Line by 1 to 34

I have a patch whereby I reset prev_pc in infrun.c:init_execution_control_state():

   if (prev_pc != 0)
     prev_pc = read_pc ();

prior to setting the ecs->sal.  This works for me in both scenarios.  The check for
0 was needed because I get a failure on the ia64 trying to read the pc too early when
the psr register was invalid.

This may or may not be the best way of doing this.  Any other platforms experiencing
this problem in call-ar-st.exp or return.exp?

-- Jeff J.

Re: prev_pc problem on ia64

[Elena Zannoni]

J. Johnston writes:
 > I am running into a problem on ia64 regarding performing a next
 > after an inferior function call or after using "return" from
 > a function.
 > 
 > What's occurring is that an inferior function call ends up setting
 > the static prev_pc value in infrun.c: stop_stepping().  When we
 > return to the gdb prompt prev_pc is not restored to its original
 > value.  A similar problem occurs when we return from a function
 > using the gdb return command.
 > 

Can you post the sequence that will make the error occur?  stop_stepping
is not called by the inferior function call code. So it must be
afterwards.

 > On the ia64, there are extraneous line table entries that do not
 > increase the line number.  When we perform a next after the inferior
 > call, we step until the line number changes from the one set for
 > prev_pc.  Unfortunately, this only gets us part way through the line as
 > we run until the next line table entry.
 > 
 > For the x86, this problem does not crop up in the test case I am looking
 > at because there are none of these additional line table entries.  When
 > we perform a next, it finds the next line regardless of the fact that prev_pc is
 > not correctly set.
 > 
 > The following is an example of the line table entries I am talking about on
 > the ia64 (generated by readelf -wl).  I am using a recent gcc but this behavior
 > also occurs for gcc 2.96
 > 
 >    Special opcode 20: advance Address by 1 to 0x40000000000007e1 and Line by 1 to 31
 >    Special opcode 215: advance Address by 15 to 0x40000000000007f0 and Line by 0 to 31
 >    Special opcode 19: advance Address by 1 to 0x40000000000007f1 and Line by 0 to 31
 >    Special opcode 19: advance Address by 1 to 0x40000000000007f2 and Line by 0 to 31
 >    Special opcode 201: advance Address by 14 to 0x4000000000000800 and Line by 0 to 31
 >    Special opcode 20: advance Address by 1 to 0x4000000000000801 and Line by 1 to 32
 >    Special opcode 243: advance Address by 17 to 0x4000000000000812 and Line by 0 to 32
 >    Special opcode 201: advance Address by 14 to 0x4000000000000820 and Line by 0 to 32
 >    Special opcode 19: advance Address by 1 to 0x4000000000000821 and Line by 0 to 32
 >    Special opcode 19: advance Address by 1 to 0x4000000000000822 and Line by 0 to 32
 >    Special opcode 201: advance Address by 14 to 0x4000000000000830 and Line by 0 to 32
 >    Special opcode 19: advance Address by 1 to 0x4000000000000831 and Line by 0 to 32
 > 

What does gdb show for info line 31 and info line 32?  How about
disasembling instructions around those lines?  I wonder if these
addresses are legitimate at all. 

 > Same function compiled for i686:
 > 
 >    Special opcode 76: advance Address by 5 to 0x804839e and Line by 1 to 31
 >    Special opcode 230: advance Address by 16 to 0x80483ae and Line by 1 to 32
 >    Special opcode 146: advance Address by 10 to 0x80483b8 and Line by 1 to 33
 >    Special opcode 160: advance Address by 11 to 0x80483c3 and Line by 1 to 34
 > 
 > I have a patch whereby I reset prev_pc in infrun.c:init_execution_control_state():
 > 
 >    if (prev_pc != 0)
 >      prev_pc = read_pc ();
 > 
 > prior to setting the ecs->sal.  This works for me in both scenarios.  The check for
 > 0 was needed because I get a failure on the ia64 trying to read the pc too early when
 > the psr register was invalid.
 > 

maybe read_pc should return an error code? Ah wait, it errors out, so
you should encapsulate that in a catch_errors().

please post the patch to gdb-patches. It's hard to judge, like this.

 > This may or may not be the best way of doing this.  Any other platforms experiencing
 > this problem in call-ar-st.exp or return.exp?
 > 

Not that I remember.

elena

 > -- Jeff J.

Re: prev_pc problem on ia64

[J. Johnston]

Elena Zannoni wrote:
> J. Johnston writes:
>  > I am running into a problem on ia64 regarding performing a next
>  > after an inferior function call or after using "return" from
>  > a function.
>  > 
>  > What's occurring is that an inferior function call ends up setting
>  > the static prev_pc value in infrun.c: stop_stepping().  When we
>  > return to the gdb prompt prev_pc is not restored to its original
>  > value.  A similar problem occurs when we return from a function
>  > using the gdb return command.
>  > 
> 
> Can you post the sequence that will make the error occur?  stop_stepping
> is not called by the inferior function call code. So it must be
> afterwards.
>

This is the next to 1237 test in gdb.base/call-ar-st.exp.

1. gdb -nw call-ar-st
2. b 1236
3. run
4. p sum_array_print (10, *list1, *list2, *list3, *list4)
5. next

Step 5 above should result in line 1237.  It does not.  We end up
part way into line 1236.

>  > On the ia64, there are extraneous line table entries that do not
>  > increase the line number.  When we perform a next after the inferior
>  > call, we step until the line number changes from the one set for
>  > prev_pc.  Unfortunately, this only gets us part way through the line as
>  > we run until the next line table entry.
>  > 
>  > For the x86, this problem does not crop up in the test case I am looking
>  > at because there are none of these additional line table entries.  When
>  > we perform a next, it finds the next line regardless of the fact that prev_pc is
>  > not correctly set.
>  > 
>  > The following is an example of the line table entries I am talking about on
>  > the ia64 (generated by readelf -wl).  I am using a recent gcc but this behavior
>  > also occurs for gcc 2.96
>  > 
>  >    Special opcode 20: advance Address by 1 to 0x40000000000007e1 and Line by 1 to 31
>  >    Special opcode 215: advance Address by 15 to 0x40000000000007f0 and Line by 0 to 31
>  >    Special opcode 19: advance Address by 1 to 0x40000000000007f1 and Line by 0 to 31
>  >    Special opcode 19: advance Address by 1 to 0x40000000000007f2 and Line by 0 to 31
>  >    Special opcode 201: advance Address by 14 to 0x4000000000000800 and Line by 0 to 31
>  >    Special opcode 20: advance Address by 1 to 0x4000000000000801 and Line by 1 to 32
>  >    Special opcode 243: advance Address by 17 to 0x4000000000000812 and Line by 0 to 32
>  >    Special opcode 201: advance Address by 14 to 0x4000000000000820 and Line by 0 to 32
>  >    Special opcode 19: advance Address by 1 to 0x4000000000000821 and Line by 0 to 32
>  >    Special opcode 19: advance Address by 1 to 0x4000000000000822 and Line by 0 to 32
>  >    Special opcode 201: advance Address by 14 to 0x4000000000000830 and Line by 0 to 32
>  >    Special opcode 19: advance Address by 1 to 0x4000000000000831 and Line by 0 to 32
>  > 
> 
> What does gdb show for info line 31 and info line 32?  How about
> disasembling instructions around those lines?  I wonder if these
> addresses are legitimate at all. 
>

The addresses are ok.  The boundaries where the line number goes up is correct.  It is
just the extraneous entries that it has problems with.

(gdb) info line 1236
Line 1236 of "/usr/src/redhat/BUILD/gdb+dejagnu-20021129/gdb/testsuite/gdb.base/call-ar-st.c" starts at address 0x40000000000051e1 <main+1681>
    and ends at 0x40000000000051f0 <main+1696>.
(gdb) info line 1237
Line 1237 of "/usr/src/redhat/BUILD/gdb+dejagnu-20021129/gdb/testsuite/gdb.base/call-ar-st.c" starts at address 0x4000000000005201 <main+1713>
    and ends at 0x4000000000005210 <main+1728>.

   Special opcode 20: advance Address by 1 to 0x40000000000051e1 and Line by 1 to 1236
   Special opcode 215: advance Address by 15 to 0x40000000000051f0 and Line by 0 to 1236
   Special opcode 19: advance Address by 1 to 0x40000000000051f1 and Line by 0 to 1236
   Special opcode 19: advance Address by 1 to 0x40000000000051f2 and Line by 0 to 1236
   Special opcode 201: advance Address by 14 to 0x4000000000005200 and Line by 0 to 1236
   Special opcode 20: advance Address by 1 to 0x4000000000005201 and Line by 1 to 1237
   Special opcode 215: advance Address by 15 to 0x4000000000005210 and Line by 0 to 1237


>  > Same function compiled for i686:
>  > 
>  >    Special opcode 76: advance Address by 5 to 0x804839e and Line by 1 to 31
>  >    Special opcode 230: advance Address by 16 to 0x80483ae and Line by 1 to 32
>  >    Special opcode 146: advance Address by 10 to 0x80483b8 and Line by 1 to 33
>  >    Special opcode 160: advance Address by 11 to 0x80483c3 and Line by 1 to 34
>  > 
>  > I have a patch whereby I reset prev_pc in infrun.c:init_execution_control_state():
>  > 
>  >    if (prev_pc != 0)
>  >      prev_pc = read_pc ();
>  > 
>  > prior to setting the ecs->sal.  This works for me in both scenarios.  The check for
>  > 0 was needed because I get a failure on the ia64 trying to read the pc too early when
>  > the psr register was invalid.
>  > 
> 
> maybe read_pc should return an error code? Ah wait, it errors out, so
> you should encapsulate that in a catch_errors().
> 
> please post the patch to gdb-patches. It's hard to judge, like this.
> 

Will do.

>  > This may or may not be the best way of doing this.  Any other platforms experiencing
>  > this problem in call-ar-st.exp or return.exp?
>  > 
> 
> Not that I remember.
> 
> elena
> 
>  > -- Jeff J.

Re: prev_pc problem on ia64

[Andrew Cagney]

(I'll ignore the debug info :-)
>  > Same function compiled for i686:
>  > 
>  >    Special opcode 76: advance Address by 5 to 0x804839e and Line by 1 to 31
>  >    Special opcode 230: advance Address by 16 to 0x80483ae and Line by 1 to 32
>  >    Special opcode 146: advance Address by 10 to 0x80483b8 and Line by 1 to 33
>  >    Special opcode 160: advance Address by 11 to 0x80483c3 and Line by 1 to 34
>  > 
>  > I have a patch whereby I reset prev_pc in infrun.c:init_execution_control_state():
>  > 
>  >    if (prev_pc != 0)
>  >      prev_pc = read_pc ();
>  > 
>  > prior to setting the ecs->sal.  This works for me in both scenarios.  The check for
>  > 0 was needed because I get a failure on the ia64 trying to read the pc too early when
>  > the psr register was invalid.
>  > 
> 
> maybe read_pc should return an error code? Ah wait, it errors out, so
> you should encapsulate that in a catch_errors().

The `prev_pc != 0' test is definitly wrong - that will only work when 
GDB first starts.  Provided the target_has_execution (?), there 
shouldn't be an error (if there is, GDB's in bad shape :-), so the 
change should always assign a value to prev_pc and, conditional on 
target_has_execution, use the value of read_pc().

I'm also left wondering if the prev_func_name assignment in:

> static void
> stop_stepping (struct execution_control_state *ecs)
> {
>   if (target_has_execution)
>     {
>       /* Assuming the inferior still exists, set these up for next
>          time, just like we did above if we didn't break out of the
>          loop.  */
>       prev_pc = read_pc ();
>       prev_func_name = ecs->stop_func_name;
>     }
> 
>   /* Let callers know we don't want to wait for the inferior anymore.  */
>   ecs->wait_some_more = 0;
> }

should also be moved to init_execution_control_state, and both of those 
assignments should be deleted.

Is it possible to move both of these into the ECS state?

> please post the patch to gdb-patches. It's hard to judge, like this.

Yes.

Andrew

Re: prev_pc problem on ia64

[J. Johnston]

Andrew Cagney wrote:
> (I'll ignore the debug info :-)
> 
>>  > Same function compiled for i686:
>>  >  >    Special opcode 76: advance Address by 5 to 0x804839e and Line 
>> by 1 to 31
>>  >    Special opcode 230: advance Address by 16 to 0x80483ae and Line 
>> by 1 to 32
>>  >    Special opcode 146: advance Address by 10 to 0x80483b8 and Line 
>> by 1 to 33
>>  >    Special opcode 160: advance Address by 11 to 0x80483c3 and Line 
>> by 1 to 34
>>  >  > I have a patch whereby I reset prev_pc in 
>> infrun.c:init_execution_control_state():
>>  >  >    if (prev_pc != 0)
>>  >      prev_pc = read_pc ();
>>  >  > prior to setting the ecs->sal.  This works for me in both 
>> scenarios.  The check for
>>  > 0 was needed because I get a failure on the ia64 trying to read the 
>> pc too early when
>>  > the psr register was invalid.
>>  >
>> maybe read_pc should return an error code? Ah wait, it errors out, so
>> you should encapsulate that in a catch_errors().
> 
> 
> The `prev_pc != 0' test is definitly wrong - that will only work when 
> GDB first starts.  Provided the target_has_execution (?), there 
> shouldn't be an error (if there is, GDB's in bad shape :-), so the 
> change should always assign a value to prev_pc and, conditional on 
> target_has_execution, use the value of read_pc().
> 

I tried to use target_has_execution but that did not work.  The error
I get is that the process does not exist.  The read_pc() routine for the ia64 is doing
a read_register_pid() and it appears that the inferior_ptid is not set up
at a time when target_has_execution is set to true.

Does this observation seem reasonable?

> I'm also left wondering if the prev_func_name assignment in:
> 
>> static void
>> stop_stepping (struct execution_control_state *ecs)
>> {
>>   if (target_has_execution)
>>     {
>>       /* Assuming the inferior still exists, set these up for next
>>          time, just like we did above if we didn't break out of the
>>          loop.  */
>>       prev_pc = read_pc ();
>>       prev_func_name = ecs->stop_func_name;
>>     }
>>
>>   /* Let callers know we don't want to wait for the inferior anymore.  */
>>   ecs->wait_some_more = 0;
>> }
> 
> 
> should also be moved to init_execution_control_state, and both of those 
> assignments should be deleted.
> 
> Is it possible to move both of these into the ECS state?
> 
>> please post the patch to gdb-patches. It's hard to judge, like this.
> 
> 
> Yes.
> 
> Andrew
> 
> 

Re: prev_pc problem on ia64

[Elena Zannoni]

J. Johnston writes:
 > Andrew Cagney wrote:
 > > (I'll ignore the debug info :-)
 > > 
 > >>  > Same function compiled for i686:
 > >>  >  >    Special opcode 76: advance Address by 5 to 0x804839e and Line 
 > >> by 1 to 31
 > >>  >    Special opcode 230: advance Address by 16 to 0x80483ae and Line 
 > >> by 1 to 32
 > >>  >    Special opcode 146: advance Address by 10 to 0x80483b8 and Line 
 > >> by 1 to 33
 > >>  >    Special opcode 160: advance Address by 11 to 0x80483c3 and Line 
 > >> by 1 to 34
 > >>  >  > I have a patch whereby I reset prev_pc in 
 > >> infrun.c:init_execution_control_state():
 > >>  >  >    if (prev_pc != 0)
 > >>  >      prev_pc = read_pc ();
 > >>  >  > prior to setting the ecs->sal.  This works for me in both 
 > >> scenarios.  The check for
 > >>  > 0 was needed because I get a failure on the ia64 trying to read the 
 > >> pc too early when
 > >>  > the psr register was invalid.
 > >>  >
 > >> maybe read_pc should return an error code? Ah wait, it errors out, so
 > >> you should encapsulate that in a catch_errors().
 > > 
 > > 
 > > The `prev_pc != 0' test is definitly wrong - that will only work when 
 > > GDB first starts.  Provided the target_has_execution (?), there 
 > > shouldn't be an error (if there is, GDB's in bad shape :-), so the 
 > > change should always assign a value to prev_pc and, conditional on 
 > > target_has_execution, use the value of read_pc().
 > > 
 > 
 > I tried to use target_has_execution but that did not work.  The error
 > I get is that the process does not exist.  The read_pc() routine for the ia64 is doing
 > a read_register_pid() and it appears that the inferior_ptid is not set up
 > at a time when target_has_execution is set to true.

target_has_execution doesn't mean that the target is executing. It is
a total misnomer to indicate that the gdb target stratum is capable of
execution. I think what you want is target_has_registers. 

elena


 > 
 > Does this observation seem reasonable?
 > 
 > > I'm also left wondering if the prev_func_name assignment in:
 > > 
 > >> static void
 > >> stop_stepping (struct execution_control_state *ecs)
 > >> {
 > >>   if (target_has_execution)
 > >>     {
 > >>       /* Assuming the inferior still exists, set these up for next
 > >>          time, just like we did above if we didn't break out of the
 > >>          loop.  */
 > >>       prev_pc = read_pc ();
 > >>       prev_func_name = ecs->stop_func_name;
 > >>     }
 > >>
 > >>   /* Let callers know we don't want to wait for the inferior anymore.  */
 > >>   ecs->wait_some_more = 0;
 > >> }
 > > 
 > > 
 > > should also be moved to init_execution_control_state, and both of those 
 > > assignments should be deleted.
 > > 
 > > Is it possible to move both of these into the ECS state?
 > > 
 > >> please post the patch to gdb-patches. It's hard to judge, like this.
 > > 
 > > 
 > > Yes.
 > > 
 > > Andrew
 > > 
 > > 
 > 

Re: prev_pc problem on ia64

[Andrew Cagney]

>  > I tried to use target_has_execution but that did not work.  The error
>  > I get is that the process does not exist.  The read_pc() routine for the ia64 is doing
>  > a read_register_pid() and it appears that the inferior_ptid is not set up
>  > at a time when target_has_execution is set to true.
> 
> target_has_execution doesn't mean that the target is executing. It is
> a total misnomer to indicate that the gdb target stratum is capable of
> execution. I think what you want is target_has_registers. 

Arrrgh!  That problem, core file's also has registers ... so right 
theory, I've no idea on which thing to use in the test though.

Andrew

Re: prev_pc problem on ia64

[Andrew Cagney]

>> 
>>  > I tried to use target_has_execution but that did not work.  The error
>>  > I get is that the process does not exist.  The read_pc() routine for the ia64 is doing
>>  > a read_register_pid() and it appears that the inferior_ptid is not set up
>>  > at a time when target_has_execution is set to true.
>> 
>> target_has_execution doesn't mean that the target is executing. It is
>> a total misnomer to indicate that the gdb target stratum is capable of
>> execution. I think what you want is target_has_registers.


> Arrrgh!  That problem, core file's also has registers ... so right theory, I've no idea on which thing to use in the test though.

Hmm, ... but at least target_has_registers should only be true when the 
target really does have the registers available.  I guess try it.

Andrew

Re: prev_pc problem on ia64

[J. Johnston]

Andrew Cagney wrote:
>>>
>>>  > I tried to use target_has_execution but that did not work.  The error
>>>  > I get is that the process does not exist.  The read_pc() routine 
>>> for the ia64 is doing
>>>  > a read_register_pid() and it appears that the inferior_ptid is not 
>>> set up
>>>  > at a time when target_has_execution is set to true.
>>>
>>> target_has_execution doesn't mean that the target is executing. It is
>>> a total misnomer to indicate that the gdb target stratum is capable of
>>> execution. I think what you want is target_has_registers.
>>
> 
> 
>> Arrrgh!  That problem, core file's also has registers ... so right 
>> theory, I've no idea on which thing to use in the test though.
> 
> 
> Hmm, ... but at least target_has_registers should only be true when the 
> target really does have the registers available.  I guess try it.
> 

Didn't work.  Still get the message:

reading register psr (#332): No such process.

Should the inferior_ptid be valid at the point that target_has_registers is true?

-- Jeff J.

Re: prev_pc problem on ia64

[J. Johnston]

Andrew Cagney wrote:
>>>
>>>  > I tried to use target_has_execution but that did not work.  The error
>>>  > I get is that the process does not exist.  The read_pc() routine 
>>> for the ia64 is doing
>>>  > a read_register_pid() and it appears that the inferior_ptid is not 
>>> set up
>>>  > at a time when target_has_execution is set to true.
>>>
>>> target_has_execution doesn't mean that the target is executing. It is
>>> a total misnomer to indicate that the gdb target stratum is capable of
>>> execution. I think what you want is target_has_registers.
>>
> 
> 
>> Arrrgh!  That problem, core file's also has registers ... so right 
>> theory, I've no idea on which thing to use in the test though.
> 
> 
> Hmm, ... but at least target_has_registers should only be true when the 
> target really does have the registers available.  I guess try it.
> 
> Andrew
> 
>

There is a problem in my choice of where to set prev_pc.  The inferior is not guaranteed
to be stopped when init_execution_control_state() is called so ptrace can fail when
asked to fetch the pc register.

I believe I have found a solution that avoids this problem by refreshing prev_pc in proceed()
just prior to resuming.  I will post a patch shortly.

-- Jeff J.