prev_pc problem on ia64

["J. Johnston" <jjohnstn at redhat dot com>]

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.