This is the mail archive of the gdb-prs@sourceware.org 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]

[Bug shlibs/11497] Stepping broken


------- Additional Comments From andre dot poenitz at nokia dot com  2010-04-14 12:50 -------
(In reply to comment #4)
> You weren't originally stopped in ld.so or in a plt when you did "step", right?

I am indeed not in ld.so, but in a  'main()' function of a tiny boiler-plate Qt
Gui application and the 'step' in question is supposed to go into the
constructor of the main window.

> How does that patch fix your problem then?

I don't know that. The problem disappears with the patch, by now this has been
verified by a colleague, too, so it's not just my imagination ;-)

> There's still a reachable call to in_solib_dynsym_resolve_code after the patch
> that you should be seeing, isn't it?  How do you not see any extra output?

I was grepping for the wrong pattern in the output. There's:

~"r 1 pc 0xaa50 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xa5b8 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xaa64 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xa5b8 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"

> ...
>        && in_solib_dynsym_resolve_code (stop_pc) <<<<<<<< here
> +      && !(ecs->event_thread->step_range_start > 1
> +	 && in_solib_dynsym_resolve_code (ecs->event_thread->step_range_start))
> 
> 
> How is this:
> 
>        && in_solib_dynsym_resolve_code (stop_pc)
> +      && !(ecs->event_thread->step_range_start > 1
> +	 && in_solib_dynsym_resolve_code (ecs->event_thread->step_range_start))
> 
> catching your case then? 

See above, my fault. Sorry.

> Are you reaching this bit at the end of
> handle_inferior_event when you do "step" ?
> 
>   /* We aren't done stepping.
> 
>      Optimize by setting the stepping range to the line.
>      (We might not be in the original line, but if we entered a
>      new line in mid-statement, we continue stepping.  This makes
>      things like for(;;) statements work better.)  */
> 
>   ecs->event_thread->step_range_start = stop_pc_sal.pc;
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   ecs->event_thread->step_range_end = stop_pc_sal.end;
>   set_step_info (frame, stop_pc_sal);
> 
>   if (debug_infrun)
>      fprintf_unfiltered (gdb_stdlog, "infrun: keep going\n");
>   keep_going (ecs);
>
> so that after a step, it looks like to gdb that you had indeed
> started a step from within ld.so or a stub (???)

[This code is not hit.]
 
> It would be also helpful to see "set debug infrun 1" before/after patch.

I'll attach this.



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11497

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


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