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: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 08 May 2015 12:02:43 +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> <86oalwvf38 dot fsf at gmail dot com>
On 05/07/2015 11:47 AM, Yao Qi wrote:
> 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,
Yes, certainly. I was just replying to this part:
> When GDBserver steps over a breakpoint in arm mode function, which
> returns to thumb mode, GDBserver will insert arm mode breakpoint by
> mistake and the program will crash. GDBserver alone is unable to
> determine the arm/thumb mode given a PC address. See how GDB does
> it in arm-tdep.c:arm_pc_is_thumb.
> 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.
Not sure about #3. We'd need some target method to get the breakpoint
opcode, like breakpoint_from_pc, but this wouldn't handle random
addresses. I think we can instead use the size parameter passed to
the_target->insert_point already. That parameter already has per-arch
meaning for breakpoint packets: 2=Thumb, 3=Thumb2, 4=ARM.
So we'd more likely end up with a breakpoint_from_size or something.
>> 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. */
Fine with me.
Thanks,
Pedro Alves