This is an archive of the discontinued LLVM Phabricator instance.

Use modern @got syntax in tsan assembly, instead of old style non_lazy_ptr's. NFC
ClosedPublic

Authored by pete on Feb 13 2023, 3:43 PM.

Details

Summary

For Apple platforms, the TSan assembly used the old style syntax to reference symbols via a non-lazy pointer slot.

Using the @gotpageoff and @gotpageoff relocations is a better way to achieve the same result, as the linker will syntheize a GOT as needed.

Diff Detail

Event Timeline

pete created this revision.Feb 13 2023, 3:43 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 13 2023, 3:43 PM
Herald added a subscriber: Enna1. · View Herald Transcript
pete requested review of this revision.Feb 13 2023, 3:43 PM
kledzik added inline comments.Feb 13 2023, 4:15 PM
compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S
106–107

The original had two setjmp pointers. One to _setjmp and one to __setjmp. I don't know if that was intentional or needed, but this changes this case to the single underscore version.

yln added inline comments.Feb 13 2023, 4:32 PM
compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S
106–107

Good catch, Nick!

Looks like this file defines 4 interceptors for:

  • setjmp
  • _setjmp
  • sigsetjmp
  • __sigsetjmp (using @page and @pageoff)

So I think it's definitely intentional (not sure about needed, but no reason to change it either?).

Is @page and @pageoff just a different spelling or different in semantics? Can we change all 4 occurrences to use the same spelling/mechanism for consistency?

pete updated this revision to Diff 497149.Feb 13 2023, 4:35 PM

Updated to fix calling the correct setjmp

yln added inline comments.Feb 13 2023, 4:38 PM
compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S
210–211

Can we also change this for consistency?

pete marked an inline comment as done.Feb 13 2023, 4:40 PM
pete added inline comments.
compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S
106–107

Good catch!

The use of ASM_SYMBOL was confusing me, as it was also adding an _. The original code didn't use it in this location, so i've removed it and just use the symbols directly.

106–107

Same semantics if you step through the code, ie, you'll see a load from a GOT. The only difference is that using the @got style syntax allows the linker to synthesize it for you, so it may choose to re-use a GOT slot for the same symbol, eg, if another function called the symbol too.

I wanted to change sigsetjmp too, but that code is actually unused on Apple. It has the #if around the use just like the others, but actually the whole ASM_SYMBOL_INTERCEPTOR(sigsetjmp) is disabled for Apple.

I can change it anyway, if you prefer, but i have no way to test it, other than perhaps trying to allow that function to build for Apple and make sure i get no assembler errors, or perhaps even that we succeed in linking the dylib. Let me know if you prefer i change it or not.

210–211

Happy to, if you like. Please see previous comments that this code is actually unused on Apple platforms right now.

yln accepted this revision.Feb 13 2023, 4:55 PM
yln added inline comments.
compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S
210–211

Ah, I missed that we have a #if !defined(__APPLE__) around the whole thing. Removing it altogether or making it an #error (so we notice in case the enclosing !APPLE is removed) are alternatives then also. I leave it up to you; it's not something that we need cleanup here.

LGTM, thanks!

I asked @wrotki or @rsundahl for a quick local sanity check (build & run tests/example). Please wait for their OK before landing.

This revision is now accepted and ready to land.Feb 13 2023, 4:55 PM
wrotki accepted this revision.Feb 14 2023, 11:04 AM

LGTM. I verified using debugger and the longjmp3 Tsan test case that he setjmp Tsan interceptor is being correctly called with tis change.

kubamracek added a reviewer: dvyukov.

Do you want me to look at something in particular? Frankly, I don't understand the details here and can't meaningfully review.
If you think it's a good change and tests pass, I would say go on and merge.

kubamracek added a reviewer: dvyukov.

Do you want me to look at something in particular? Frankly, I don't understand the details here and can't meaningfully review.
If you think it's a good change and tests pass, I would say go on and merge.

That's all I wanted :) Thanks!

kubamracek accepted this revision.Feb 15 2023, 3:26 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 20 2023, 2:47 PM
Herald added a subscriber: Restricted Project. · View Herald Transcript