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

[Pedro Alves <palves@redhat.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