From: Yao Qi <qiyaoltc@gmail.com>
To: Pedro Alves <palves@redhat.com>
Cc: Yao Qi <qiyaoltc@gmail.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] [gdbserver] Disable conditional breakpoints on no-hardware-single-step targets
Date: Thu, 07 May 2015 10:48:00 -0000 [thread overview]
Message-ID: <86oalwvf38.fsf@gmail.com> (raw)
In-Reply-To: <554A368F.4060309@redhat.com> (Pedro Alves's message of "Wed, 06 May 2015 16:43:11 +0100")
Pedro Alves <palves@redhat.com> writes:
> Of a random PC address no, but in gdbserver's case, I think that it
> would work, because we need it to step over a breakpoint that is
> at the current PC. So we could:
>
> #1 - Get the mode of the current PC from the thread's $cpsr register.
>
> #2 - Get the mode of the next PC by looking at the instruction that is
> about to be executed (at current PC). If bx and blx, which change
> modes, check the thumb bit of the destination address.
> For all other instructions, same mode as the current PC.
>
We can know the mode of the next PC in this way, but we don't know the
address of the next PC. In fact, we need to know the address of the
next PC first, and then determine the mode of the next PC. Probably, we
need something as below,
1. Teach GDBserver to compute the address of the next PC,
2. Determine the mode of the next PC as you suggested,
3. Add breakpoint_from_pc hook in target_ops, so that the right
breakpoint instruction can be selected.
>>
>> After thinking about how to teach GDBserver inserting right breakpoint
>> (arm or thumb) for a while, I reconsider it from a different direction
>> that it may be unreasonable to run target-side conditional breakpoint for
>> targets without hardware single step. Pedro also pointed this out here
>> https://sourceware.org/ml/gdb-patches/2015-04/msg00337.html
>
> In the end I was somewhat convinced that things ended up working.
> But I certainly don't object to this patch.
>
>> + /* Although win32-i386 has hardware single step, still disable this
>> + feature for win32, because it is quite GNU/Linux specific. */
>> + NULL, /* supports_conditional_breakpoints */
>
> TBC, it's not that the feature is GNU/Linux specific (like something
> related to system calls or some detail in glibc), but that the support
> for conditional breakpoints is baked into linux-low.c instead of
> in generic code.
How about writing comments like this?
/* Although win32-i386 has hardware single step, still disable this
feature for win32, because it is implemented in linux-low.c instead
of in generic code. */
--
Yao (齐尧)
next prev parent reply other threads:[~2015-05-07 10:48 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1430411029-12097-1-git-send-email-qiyaoltc@gmail.com>
[not found] ` <55426205.3070901@ericsson.com>
2015-05-01 14:18 ` Yao Qi
2015-05-08 12:18 ` Luis Machado
2015-05-08 13:14 ` Yao Qi
2015-05-06 15:43 ` Pedro Alves
2015-05-07 10:48 ` Yao Qi [this message]
2015-05-07 11:45 ` Antoine Tremblay
2015-05-08 11:50 ` Pedro Alves
2015-05-08 12:12 ` Antoine Tremblay
2015-05-08 12:29 ` Pedro Alves
2015-05-08 12:35 ` Antoine Tremblay
2015-05-08 11:02 ` Pedro Alves
2015-05-10 1:04 ` Maciej W. Rozycki
2015-05-11 11:31 ` Pedro Alves
2015-05-11 12:38 ` Maciej W. Rozycki
2015-05-11 14:08 ` Pedro Alves
2015-05-11 17:40 ` Maciej W. Rozycki
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=86oalwvf38.fsf@gmail.com \
--to=qiyaoltc@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.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