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] |
(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.
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] |