This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: prev_pc problem on ia64


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





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]