This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] gdbserver gnu/linux: stepping over breakpoint
- From: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>, gdb-patches at sourceware dot org
- Date: Thu, 09 Apr 2015 10:26:26 +0100
- Subject: Re: [PATCH] gdbserver gnu/linux: stepping over breakpoint
- Authentication-results: sourceware.org; auth=none
- References: <1428569112-18004-1-git-send-email-qiyaoltc at gmail dot com>
On 04/09/2015 09:45 AM, Yao Qi wrote:
> From: Yao Qi <yao.qi@linaro.org>
>
> Hi,
> I see the following error on arm linux gdbserver,
>
> continue^M
> Continuing.^M
> ../../../binutils-gdb/gdb/gdbserver/linux-arm-low.c:458: A problem internal to GDBserver has been detected.^M
> raw_bkpt_type_to_arm_hwbp_type: unhandled raw type^M
> Remote connection closed^M
> (gdb) FAIL: gdb.base/cond-eval-mode.exp: hbreak: continue
>
> After we make GDBserver handling Zx/zx packet idempotent,
>
> [PATCH 3/3] [GDBserver] Make Zx/zx packet handling idempotent.
> https://sourceware.org/ml/gdb-patches/2014-04/msg00480.html
>
>> Now removal/insertion of all kinds of breakpoints/watchpoints, either
>> internal, or from GDB, always go through the target methods.
>
> GDBserver handles all kinds of breakpoints/watchpoints through target
> methods. However, some target backends, such as arm, don't support Z0
> packet but need software breakpoint to do breakpoint stepping over in
> linux-low.c:start_step_over,
>
> if (can_hardware_single_step ())
> {
> step = 1;
> }
> else
> {
> CORE_ADDR raddr = (*the_low_target.breakpoint_reinsert_addr) ();
> set_reinsert_breakpoint (raddr);
> step = 0;
> }
>
> a software breakpoint is requested to the backend, and the error is
> triggered. This problem should affect targets having
> breakpoint_reinsert_addr hooked.
BTW, I think the patch is OK on its own right, as it would be
needed to step over thread event breakpoints on older kernels (that's
all breakpoint_reinsert_addr handles, see comment above start_step_over),
but gdbserver shouldn't be using those event breakpoints nowadays
(thread_db_use_events ends up false), so it's surprising that that's
even reached. The test isn't even threaded. It sounds like
gdbserver is trying to step over the breakpoint at "foo"? Didn't
gdb itself step over it? How come that was reached in gdbserver?
Did we mishandle the breakpoint's reference count in gdbserver?
Thanks,
Pedro Alves