Link with -z now or -bind_at_load. (#14562)
commite7f9dbe73c3344c96a13892a6c4c45f8e5c35aa3
authorJay Krell <jay.krell@cornell.edu>
Fri, 5 Jul 2019 13:54:17 +0000 (5 06:54 -0700)
committerAlexander Köplinger <alex.koeplinger@outlook.com>
Fri, 5 Jul 2019 13:54:16 +0000 (5 15:54 +0200)
treee234bfa1cdc3673a356747f135cfe75737b533f3
parent4cf527f6d9ce224c8d1972c95e212f74a0c91043
Link with -z now or -bind_at_load. (#14562)

Advantages:
 Dynamic linker gets out of the way of random function calls,
 in terms of timing, in terms of locking, and in term of success,
 and possibly in terms of security (readonly function pointers).
 If you successfully load, then you can make function calls with impunity,
 without regard as to if they are in the same .so as the caller, well,
 assuming they are to a leaf like libc, or to something itself built with -z now.

 The "success" is significant, as otherwise loaded LLVM has unresolved symbols lurking, depending on which code paths you send it down.

Disadvantage: Slower startup.

Mixed:
 Platform consistency, since this is how Windows behaves usually (unless you say link /delayload)

This will combine well with an upcoming revision of https://github.com/mono/mono/pull/14524.

Difficult alternative: Force the binding along sensitive paths by calling their callees earlier.
Typical alternative: Ignore the matter.

Android: It is believed this switch produces a warning, which is ignored, there is no affect, and it is unclear if the behavior is actually "now" or "lazy". Logs could be checked and a test run, but neither.
configure.ac
m4/ax_append_flag.m4 [new file with mode: 0644]
m4/ax_append_link_flags.m4 [new file with mode: 0644]
m4/ax_check_link_flag.m4 [new file with mode: 0644]
m4/ax_require_defined.m4 [new file with mode: 0644]