This is an archive of the discontinued LLVM Phabricator instance.

Use BKPT instead of UDF for arm/thumb breakpoints
ClosedPublic

Authored by tberghammer on Feb 3 2016, 6:46 AM.

Details

Summary

Use BKPT instead of UDF for arm/thumb breakpoints

The UDF instruction is deprecated in armv7 and in case of thumb2 instructions set it don't work well together with the IT instruction.

Diff Detail

Repository
rL LLVM

Event Timeline

tberghammer updated this revision to Diff 46782.Feb 3 2016, 6:46 AM
tberghammer retitled this revision from to Use BKPT instead of UDF for arm/thumb breakpoints.
tberghammer updated this object.
tberghammer added reviewers: clayborg, omjavaid.
tberghammer added a subscriber: lldb-commits.
clayborg requested changes to this revision.Feb 3 2016, 10:17 AM
clayborg edited edge metadata.

There are immediate values you can play around with inside the BKPT instruction of both ARM and Thumb versions so that the two least significant bytes are the same:

static const uint8_t g_arm_breakpoint_opcode[] = { 0x70, 0xBE, 0x20, 0xE1 };
static const uint8_t g_thumb_breakpoint_opcode[] = { 0x70, 0xBE };

Note both start with 0xBE70 when using the above definitions. This means if you guess wrong and set an ARM breakpoint in Thumb code, you will still stop and not hose your program over. I would recommend using these values just to be safe.

This revision now requires changes to proceed.Feb 3 2016, 10:17 AM
tberghammer updated this revision to Diff 46899.Feb 4 2016, 5:05 AM
tberghammer edited edge metadata.

Update breakpoint opcodes based on review

omjavaid edited edge metadata.Feb 9 2016, 12:41 AM

GDB doesnt use bkpt instruction for user debugging for the reason that it interferes with jtag debug probes. I am not sure if LLDB will be ever used with a jtag probe in near future but still a jtag prob might be connected to the same hardware which is using LLDB to debug a user space application.

heres a discussion which happened some years back on similar issues:

https://sourceware.org/ml/gdb-patches/2010-01/msg00624.html

http://www.spinics.net/lists/arm-kernel/msg80476.html

I am fine with using bkpt as long as it helps us debug IT blocks and doesnt interfere with any of our currently functionality.

GDB doesnt use bkpt instruction for user debugging for the reason that it interferes with jtag debug probes. I am not sure if LLDB will be ever used with a jtag probe in near future but still a jtag prob might be connected to the same hardware which is using LLDB to debug a user space application.

The change is restricted to Linux and I am pretty sure that if somebody want to do jtag debugging with LLDB then he/she have to implement a new platform module. If a separate jtag probe is connected to the hardware then it might cause an issue but I don't think we have any user who is doing it (why would you use 2 debugging at the same time?)

heres a discussion which happened some years back on similar issues:

https://sourceware.org/ml/gdb-patches/2010-01/msg00624.html

http://www.spinics.net/lists/arm-kernel/msg80476.html

If we hit the issues they are mentioning with using the BKPT instruction then we have to implement some workarounds for it but as they describe they are not perfect so I would rather avoid them.

I am fine with using bkpt as long as it helps us debug IT blocks and doesnt interfere with any of our currently functionality.

I run the test suit and nothing showed up so I think we are mostly safe in this side.

clayborg accepted this revision.Feb 9 2016, 12:53 PM
clayborg edited edge metadata.

Looks good. Most JTAG probes actually vend their own GDB server these days. If so, we will used the Z packets in order to set breakpoints, so we will be isolated from these issues. If we add a native JTAG Process plug-in, it will be coded to "do the right thing" and it won't re-use this code, so this code should be good to go.

This revision is now accepted and ready to land.Feb 9 2016, 12:53 PM
This revision was automatically updated to reflect the committed changes.

Hi Tamas,

This commit causes a SIGBUS for me on Nexus 6 ARMv7 devices, specifically the g_thumb_breakpoint_opcode change.
I can revert this locally but any advice on tracking the issue down further?

Hi Ewan,

Can you give me some instruction about how can I reproduce the issue on a
Nexus 6? (If you can't gave the information out then the disassembly of the
offending function and the fault address might gave me some hint as well)

A SIGBUS error looks a bit strange for me but my best guess is that we
manage to install a 2 byte thumb breakpoint on the 2nd 2 byte of a 4 byte
instruction what results in an incorrect instruction opcode and from that
point strange things can happen.

Tamas