This is the mail archive of the
mailing list for the GDB project.
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
> > 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:
stop_stepping (struct execution_control_state *ecs)
/* Assuming the inferior still exists, set these up for next
time, just like we did above if we didn't break out of the
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.