Re: [PATCH] [gdbserver] Disable conditional breakpoints on no-hardware-single-step targets

Pedro Alves
2015-05-08T11:02:49Z

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