Page MenuHomePhabricator

Explicitly set entry point arch when it's thumb [Second Try]
ClosedPublic

Authored by aadsm on Oct 4 2019, 6:42 PM.

Details

Summary

This is a redo of D68069 because I reverted it due to some concerns that were now addressed along with the new comments that @labath added.

I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb).
The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash.
This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb.

I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code.

I also run the following on the command line with the app_process32 where I found the issue:
Before:

(lldb) dis -s 0x1640 -e 0x1644
app_process32[0x1640]: .long  0xf0004668                ; unknown opcode

After:

(lldb) dis -s 0x1640 -e 0x1644
app_process32`:
app_process32[0x1640] <+0>: mov    r0, sp
app_process32[0x1642]:      andeq  r0, r0, r0

Diff Detail

Event Timeline

aadsm created this revision.Oct 4 2019, 6:42 PM
labath added inline comments.Oct 7 2019, 2:00 AM
lldb/lit/SymbolFile/Breakpad/symtab.test
20

Could you change the address of the entry point (in basic-elf.yaml) to something like 0x400100 to show that the breakpad symbols resolve correctly in the case where the entry point does not get in the way.

aadsm updated this revision to Diff 223707.Oct 7 2019, 5:40 PM

Don't destroy the Breakpad test purpose.

labath accepted this revision.Oct 8 2019, 5:17 AM
This revision is now accepted and ready to land.Oct 8 2019, 5:17 AM
This revision was automatically updated to reflect the committed changes.
shafik added a subscriber: shafik.Oct 9 2019, 10:05 AM

SymbolFile/Breakpad.symtab.test is failing on green dragon cmake build see: http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/2378/

aadsm added a comment.Oct 9 2019, 10:13 AM

@shafik thanks, checking.

aadsm added a comment.Oct 9 2019, 11:01 AM

@shafik I just pushed a fix, the issue was because on mac there are more unnamed symbols so the number didn't match, I changed it to match any number since this can easily change.