Re: prev_pc problem on ia64

[Elena Zannoni <ezannoni@redhat.com>]

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.