From: Pedro Alves <palves@redhat.com>
To: Yao Qi <qiyaoltc@gmail.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdbserver gnu/linux: stepping over breakpoint
Date: Thu, 09 Apr 2015 15:29:00 -0000 [thread overview]
Message-ID: <55269AEA.8080007@redhat.com> (raw)
In-Reply-To: <552699C8.9070001@redhat.com>
On 04/09/2015 04:24 PM, Pedro Alves wrote:
> On 04/09/2015 04:22 PM, Pedro Alves wrote:
>> 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:
>
> Sorry, "si" probably works as gdb steps over the breakpoint
> itself. Try "step" or "next" instead, which kick in the range
> stepping support, which then causes gdbserver to handle the
> step-over itself.
Hmm^2, no, range stepping couldn't possibly work correctly with
that limited software single-step support. Duh. We only
enable range stepping on x86, even.
So maybe that's "good enough" for stepping past conditional
breakpoints in practice. Guess we should update the comments
to mention this.
Thanks,
Pedro Alves
prev parent reply other threads:[~2015-04-09 15:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-09 8:45 Yao Qi
2015-04-09 9:04 ` Pedro Alves
2015-04-09 9:25 ` Yao Qi
2015-04-09 9:26 ` Pedro Alves
2015-04-09 15:06 ` Yao Qi
2015-04-09 15:22 ` Pedro Alves
2015-04-09 15:25 ` Pedro Alves
2015-04-09 15:29 ` Pedro Alves [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55269AEA.8080007@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=qiyaoltc@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox