This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Fix up code addresses in RegisterContextUnwind
ClosedPublic

Authored by JDevlieghere on Apr 14 2021, 6:49 PM.

Details

Summary

Call into the ABI to fixup code addresses in RegisterContextUnwind. We need this in order to debug on Apple Silicon where libraries like libSystem are arm64e even when the inferior is arm64.

Diff Detail

Event Timeline

JDevlieghere created this revision.Apr 14 2021, 6:49 PM
JDevlieghere retitled this revision from [lld] Fix up code addresses in RegisterContextUnwind to [lldb] Fix up code addresses in RegisterContextUnwind.Apr 14 2021, 6:52 PM

Check for mask == -1

jasonmolenda accepted this revision.Apr 15 2021, 10:11 PM

This looks good. Jonas, what do you think about having FixDataAddress() methods in the ABI's. We're going to be quickly sprinkling FixCodeAddress calls throughout lldb at places where Linux/Darwin ABI need them, and it'd be nice if we have the FixDataAddress method available (even if they're identical right now) so someone doesn't need to audit all the calls in the future and adjust them as appropriate.

Or we can go with FixCodeAddress and leave this for someone to do when it actually matters -- some people will probably pick the wrong call as we add them, so it's not going to work bug-free when such a system exists. I'm honestly fine with just landing this and leaving that work for when it would actually be exercised.

(the two cases I can think of, where you'd call FixDataAddress, on Darwin might be where we get the vtable pointer, and when a ptrauth qualifier has been added to a type by the user in their program.)

This revision is now accepted and ready to land.Apr 15 2021, 10:11 PM

Implement both FixCodeAddress and FixDataAddress.

This looks good. Jonas, what do you think about having FixDataAddress() methods in the ABI's. We're going to be quickly sprinkling FixCodeAddress calls throughout lldb at places where Linux/Darwin ABI need them, and it'd be nice if we have the FixDataAddress method available (even if they're identical right now) so someone doesn't need to audit all the calls in the future and adjust them as appropriate.

Or we can go with FixCodeAddress and leave this for someone to do when it actually matters -- some people will probably pick the wrong call as we add them, so it's not going to work bug-free when such a system exists. I'm honestly fine with just landing this and leaving that work for when it would actually be exercised.

(the two cases I can think of, where you'd call FixDataAddress, on Darwin might be where we get the vtable pointer, and when a ptrauth qualifier has been added to a type by the user in their program.)

Yep, that all makes sense. I added the method and implemented both in terms of FixAddress (which takes a pc and a mask) allowing me to avoid the some of the code duplication.

Save a line or two

This revision was landed with ongoing or failed builds.Apr 16 2021, 1:49 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptApr 16 2021, 1:49 PM