If an exported symbol is linked into a DSO, it may be preempted by a
definition in the main executable. If this happens to an allocator symbol, it
will mean that the DSO will use the main executable's allocator. This is
normally relatively harmless -- regular allocations should all use the same
allocator, but if the DSO tries to hook the allocator it will not see any
allocations.

However, if LLVM LTO is enabled, the compiler may inline the shim layer
symbols into callers. The end result is that allocator calls in DSOs may use
either the main executable's allocator or the DSO's allocator, depending on
whether the call was inlined. This is arguably a bug in LLVM caused by its
somewhat irregular handling of symbol interposition (see llvm.org/PR23501).
To work around the bug we use noinline to prevent the symbols from being
inlined.

In the long run we probably want to avoid linking the allocator bits into
DSOs altogether. This will save a little space and stop giving DSOs the false
impression that they can hook the allocator.

BUG=617732
R=primiano@chromium.org

Review-Url: https://codereview.chromium.org/2748083004
Cr-Commit-Position: refs/heads/master@{#457103}