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>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 09 Apr 2015 16:22:13 +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> <552645C2 dot 6080004 at redhat dot com> <86y4m1uysh dot fsf at gmail dot com>
On 04/09/2015 04:06 PM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
>
>> 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?
>
> Shouldn't GDBserver step over breakpoint when the target side condition
> is false?
Oh, this is stepping past an hardware breakpoint, not software
breakpoint. Yes, GDBserver should be stepping past such
breakpoints. But, given GDBserver's software single-step
support is really really really really too simple:
/* We only place breakpoints in empty marker functions, and thread locking
is outside of the function. So rather than importing software single-step,
we can just run until exit. */
static CORE_ADDR
arm_reinsert_addr (void)
{
struct regcache *regcache = get_thread_regcache (current_thread, 1);
unsigned long pc;
collect_register_by_name (regcache, "lr", &pc);
return pc;
}
... we should probably disable target side conditions on software
single-step gdbserver ports. E.g., try "si" through this function:
void
function ()
{
i = 0;
i = 0; // set cond breakpoint that evals false here
i = 0;
}
I'd guess the "si" over the breakpoint ends in the caller
of "function"...
Thanks,
Pedro Alves