Re: prev_pc problem on ia64

["J. Johnston" <jjohnstn@redhat.com>]

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.