This is an archive of the discontinued LLVM Phabricator instance.

[test][compiler-rt] Avoid LD_PRELOAD for "outer" dynamic linkers
ClosedPublic

Authored by hubert.reinterpretcast on May 10 2020, 4:14 PM.

Details

Summary

This patch moves the setting of LD_PRELOAD "inwards" to avoid issues where the built library needs to be loaded with the dynamic linker that was configured with the build (and cannot, for example, be loaded by the dynamic linker associated with the env utility).

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptMay 10 2020, 4:14 PM
Herald added subscribers: Restricted Project, dberris. · View Herald Transcript
jsji added a comment.May 21 2020, 12:36 PM

issues where the built library needs to be loaded with the dynamic linker that was configured with the build (and cannot, for example, be loaded by the dynamic linker associated with the env utility).

No sure I understand the issues. %env_asan_opts will be substituted to env ASAN_OPTIONS=... in LIT run as well. If the libraray can NOT be loaded by the dynamic linker associated with env, then why it will work with env ASAN_OPTIONS=... .. LD_PRELOAD=... now?

No sure I understand the issues. %env_asan_opts will be substituted to env ASAN_OPTIONS=... in LIT run as well. If the libraray can NOT be loaded by the dynamic linker associated with env, then why it will work with env ASAN_OPTIONS=... .. LD_PRELOAD=... now?

This would be because the dynamic loader associated with env no longer has LD_PRELOAD set in its environment.

nemanjai accepted this revision.May 22 2020, 3:17 AM

So if I interpret this correctly, the existing behaviour will end up with something like env LD_PRELOAD=<lib> env ASAN_OPTIONS=<opts> not ...
which will run the inner env with LD_PRELOAD set. This patch flattens this to have only one invocation of env and sets both environment variables for the actual command.

I think this makes sense as long as %env_asan_opts does not end up expanding to something different on some platform (which I don't imagine is the case judging by the name).

LGTM.

This revision is now accepted and ready to land.May 22 2020, 3:17 AM
jsji accepted this revision.May 22 2020, 8:23 AM

Thanks LGTM too.

vitalybuka accepted this revision.May 26 2020, 2:23 PM
This revision was automatically updated to reflect the committed changes.