This is the mail archive of the
mailing list for the GDB project.
Re: [pushed] gdbserver: redo stepping over breakpoint that was on top of a permanent breakpoint
- From: Antoine Tremblay <antoine dot tremblay at ericsson dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: <gdb-patches at sourceware dot org>
- Date: Thu, 24 Sep 2015 12:43:11 -0400
- Subject: Re: [pushed] gdbserver: redo stepping over breakpoint that was on top of a permanent breakpoint
- Authentication-results: sourceware.org; auth=none
- References: <1424723261-15719-1-git-send-email-palves at redhat dot com> <861tdo9jy6 dot fsf at gmail dot com> <5603E0F7 dot 10205 at ericsson dot com> <86wpvg7y22 dot fsf at gmail dot com>
On 09/24/2015 09:21 AM, Yao Qi wrote:
Antoine Tremblay <firstname.lastname@example.org> writes:
Indeed I have a fix for this see :
Ah, I did read your patch, but I forget it when I am fixing this problem.
Np, I think that patch is valid with the scenario you mention below,
however since it won't work properly as reinsert_addr doesn't work at
this stage I think it may be better to introduce it when I post the
single stepping support ?
It can be triggered when GDBserver steps over its breakpoints, what I
did is to pass 1 to thread_db_init, so that GDBserver will insert
breakpoint on __nptl_create_event. Once a new thread is created, and
hits this breakpoint, GDBserver will step over this breakpoint.
Haa I had missed that scenario!
@@ -3010,7 +3010,8 @@ linux_wait_1 (ptid_t ptid,
Advance the PC manually past the breakpoint, otherwise the
program would keep trapping the permanent breakpoint forever. */
if (!ptid_equal (step_over_bkpt, null_ptid)
- && event_child->stop_reason == TARGET_STOPPED_BY_SW_BREAKPOINT)
+ && event_child->stop_reason == TARGET_STOPPED_BY_SW_BREAKPOINT
+ && gdb_breakpoint_here (event_child->stop_pc))
int increment_pc = 0;
CORE_ADDR stop_pc = event_child->stop_pc;
This won't work as that single step breakpoint is not a gdb breakpoint
we need to check for a reinsert breakpoint like the patch I mentioned.
I tested the scenario with my patch and the issue is solved.
Note however I'm a bit concerted about the hack to remote_check_symbols.
I need to dig into it to understand that one should we expect it to
work without this hack ?