This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] [gdbserver] Disable conditional breakpoints on no-hardware-single-step targets
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Yao Qi <qiyaoltc at gmail dot com>, gdb-patches at sourceware dot org
- Date: Thu, 07 May 2015 11:47:55 +0100
- Subject: Re: [PATCH] [gdbserver] Disable conditional breakpoints on no-hardware-single-step targets
- Authentication-results: sourceware.org; auth=none
- References: <1430411029-12097-1-git-send-email-qiyaoltc at gmail dot com> <554A368F dot 4060309 at redhat dot com>
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 (éå)