Re: prev_pc problem on ia64

[Elena Zannoni <ezannoni@redhat.com>]

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