Link with -z now or -bind_at_load. (mono/mono#14562)
authorJay Krell <jay.krell@cornell.edu>
Fri, 5 Jul 2019 13:54:17 +0000 (06:54 -0700)
committerAlexander Köplinger <alex.koeplinger@outlook.com>
Fri, 5 Jul 2019 13:54:16 +0000 (15:54 +0200)
commit9aa7f604ae320127be1b1523177dfd44946cffc8
tree4c3debec11af89a69f0bb44ad64c603ed300130e
parentba61237b68c980d92da9b8be6025afd525d68898
Link with -z now or -bind_at_load. (mono/mono#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.

Commit migrated from https://github.com/mono/mono/commit/e7f9dbe73c3344c96a13892a6c4c45f8e5c35aa3
src/mono/configure.ac
src/mono/m4/ax_append_flag.m4 [new file with mode: 0644]
src/mono/m4/ax_append_link_flags.m4 [new file with mode: 0644]
src/mono/m4/ax_check_link_flag.m4 [new file with mode: 0644]
src/mono/m4/ax_require_defined.m4 [new file with mode: 0644]