This is the mail archive of the gdb-patches@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]

Re: [PATCH] gdbserver gnu/linux: stepping over breakpoint


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


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