[lldb-dev] DYLDRendezvous setting ARM breakpoint in THUMB code

Aidan Dodds aidan at codeplay.com
Fri Jun 12 09:42:39 PDT 2015

Hello all,

This week I have been seeing lldb-server reporting an Illegal 
Instruction signal when a shared library is loaded while debugging an 
(ARM) android executable.
I have traced this back to the DYLD Rendezvous breakpoint being inserted 
as an ARM breakpoint when it should be THUMB.

I have attached a very rough patch that will fix this problem, but I 
wanted to check with the list to try and find a robust solution that 
will work in all cases.

Here are the key parts of the problem:
- The rendezvous breakpoint address is not a public symbol so is marked 
as eAddressClassUnknown.
- When the rendezvous breakpoint address is read from the DT_DEBUG 
structure it has bit 0 set which marks it as THUMB.
- Once the address is found it calls into Process::CreateBreakpointSite 
(), which in turn calls Target::GetOpcodeLoadAddress ().
- GetOpcodeLoadAddress() checks if the machine type is ARM and will mask 
out bit 0, at which point all information that it is a THUMB address has 
been lost.
- Down the line PlatformLinux::GetSoftwareBreakpointTrapOpcode() will 
see that bit 0 is not set and so will insert a ARM trap opcode.

My temporary solution was to not strip bit 0 from an address marked as 
eAddressClassUnknown in GetOpcodeLoadAddress() and also make the check in
GetSoftwareBreakpointTrapOpcode() more relaxed.

I feel this may have repercussions in other scenarios I'm not considering.
Does anyone have any thoughts or advice for a good solution to this problem?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dyld_thumb_fix.patch
Type: text/x-patch
Size: 2895 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150612/ddc12df2/attachment.bin>

More information about the lldb-dev mailing list