search for: interposition

Hi everyone, Clang/LLVM's support for ELF interposition is in a confusing state, and I propose making a few (hopefully simple) adjustments in order to bring our model into a self-consistent state. The problem: On ELF systems, global symbols can be interposed. This means, for example, that calls to global functions in some (shared) library defined in t...

...decode as weak+interposable and the old weak_odr to decode as weak. Some more prior discussion: https://reviews.llvm.org/D19995#423481 On Tue, Nov 29, 2016 at 8:01 AM, Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi everyone, > > Clang/LLVM's support for ELF interposition is in a confusing state, and I > propose making a few (hopefully simple) adjustments in order to bring our > model into a self-consistent state. > > The problem: On ELF systems, global symbols can be interposed. This means, > for example, that calls to global functions in some (share...

...; gcc -fPIC -O1 -S -o - test.c > > > > > > GCC will refuse to inline foo into bar, or use any information > > > about > > > foo in compiling bar, because foo is exported in the dynamic > > > symbol > > > table, and thus replaceable via symbol interposition. > > > > > > Clang assumes that you won't do that, or that you don't care what > > > happens if you do. It will happily inline. And, in absense of > > > inlining (e.g. if foo is too long to inline), clang will deduce > > > function attributes...

...treat this as if it were protected, but we'll keep it a secret from the linker, ssssh...", and also allow for the "usual" ELF default visibility behavior. You don't mention in your proposal anything about changing the existing behavior when the current-default -fno-semantic-interposition is in effect. But, I think we do need to change it. LLVM ought to be consistent with itself -- that part of my original argument remains just as valid. That is: if we're going to assume attributes of functions with visible definitions, based on their definitions, we should also be generating a...

...ibility(“protected”))) on a strong definition would just map >> to ordinary non-hidden external linkage, which the backend would turn into >> STV_PROTECTED. >> >> __attribute__((visibility(“default”))) on a strong definition would map the >> same way unless -fsemantic-interposition was enabled. >> >> The point of removing protected visibility is that we don’t actually honor >> default visibility in the ELF sense, so it’s silly to pretend that LLVM >> visibility is the same as ELF visibility. ELF protected visibility is basically >> the semantic...

...(); } > > Now, compare: > clang -fPIC -O1 -S -o - test.c > gcc -fPIC -O1 -S -o - test.c > > GCC will refuse to inline foo into bar, or use any information about foo > in compiling bar, because foo is exported in the dynamic symbol table, and > thus replaceable via symbol interposition. > > Clang assumes that you won't do that, or that you don't care what happens > if you do. It will happily inline. And, in absense of inlining (e.g. if foo > is too long to inline), clang will deduce function attributes about foo and > rely on those in bar -- despite that th...

...t;rnk at google.com>, "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, November 29, 2016 11:34:56 AM > Subject: Re: [llvm-dev] RFC: Add an "interposible" linkage type (and > implement -fsemantic-interposition) > On Tue, Nov 29, 2016 at 9:15 AM Reid Kleckner via llvm-dev < > llvm-dev at lists.llvm.org > wrote: > > I think that all makes sense. You're just adding the missing > > non-ODR > > conterpart of 'external' linkage. I could imagine having "external...

+kledzik at apple.com The dynamic runtime is using dylib interposition (google for "__DATA,__interpose). If I'm understanding correctly (Nick, can you please confirm this?) this allows to interpose the function regardless of the two-level namespace. The support for dynamic runtime in ASan is almost there. But the new interposition method has revealed some iss...

...eaningful for weak definitions. > GCC must do *some* inlining between strong definitions. Do you know what their rule is? Is it just a C++ thing? > > GCC only inlines strong definitions when -fPIC is disabled, meaning the code will be linked into the main executable. In this case, no interposition can occur because dynamic symbol search always starts in the executable. They also have -fno-semantic-interposition, which allows inlining strong definitions: > https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Optimize-Options.html#index-fsemantic-interposition-972 <https://gcc.gnu.org/onlinedocs...

On Tue, Dec 04, 2012 at 09:46:09AM -0800, Alexander Potapenko wrote: > +kledzik at apple.com > The dynamic runtime is using dylib interposition (google for > "__DATA,__interpose). > If I'm understanding correctly (Nick, can you please confirm this?) > this allows to interpose the function regardless of the two-level > namespace. > The support for dynamic runtime in ASan is almost there. But the new > interpositio...

> On Mar 11, 2016, at 8:33 AM, Reid Kleckner <rnk at google.com> wrote: > On Thu, Mar 10, 2016 at 10:32 PM, John McCall via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > I mean, I’ve never really liked ELF’s stance on symbol interposition, but taking it as given, I’m not sure I agree that it’s reasonable to carve out virtual functions as a general exception. > > Given that LLVM does IPO (inlining, funcattrs) on symbols that can be interposed on ELF, we already don't support interposability very well: > https://llvm.org...

...ter than it could be, we must have both). This makes us depend on CoreFoundation to call CFAllocatorSetDefault. Because of some bugs in CF which start firing after CFAllocatorSetDefault, we have to add several hacks to circumvent the effects of those bugs. The current hypothesis is that using dylib interposition for memory allocation routines (instead of playing with malloc zones) will allow us to remove the CF dependency together with all the hacks. I'm trying to check if this is true. The current plan is to have dynamic runtime for both iOS (for which we don't have any other option) and Mac OS....

...weak_for_linker symbols. __attribute__((visibility(“protected”))) on a strong definition would just map to ordinary non-hidden external linkage, which the backend would turn into STV_PROTECTED. __attribute__((visibility(“default”))) on a strong definition would map the same way unless -fsemantic-interposition was enabled. The point of removing protected visibility is that we don’t actually honor default visibility in the ELF sense, so it’s silly to pretend that LLVM visibility is the same as ELF visibility. ELF protected visibility is basically the semantics LLVM already assigns to default visibility....

On 30 November 2012 13:32, Alexander Potapenko <glider at google.com> wrote: > No, we are not going to use mach_inject. This isn't portable and may > be even harder to set up than mach_override. > The new ASan runtime will use the dylib interposition and will in fact > require DYLD_INSERT_LIBRARIES to work. However ASan already handles it > correctly itself: if the corresponding env var is missing the app is > just re-execed. > Dylib interposition is supported by Apple and should work on iOS as > well as Mac OS. It will also prob...

...t; LD_PRELOAD, etc.) and I don't see how virtual functions are any different. > I think default LLVM behavior needs to be consistent for all > inter-procedural optimizations (be it inlining, devirtualization or > cloning). > > Maybe it's time to resurrect Hal's -fsemantic-interposition flag and use > it consistently throughout compiler? Users who need GCC-like semantics will > be able to employ this flag to prevent unsafe optimizations. > -fsemantic-interposition controls whether the compiler may assume that symbols are not interposed, and it has nothing to do with the...

...must have both). This > makes us depend on CoreFoundation to call CFAllocatorSetDefault. > Because of some bugs in CF which start firing after > CFAllocatorSetDefault, we have to add several hacks to circumvent the > effects of those bugs. > The current hypothesis is that using dylib interposition for memory > allocation routines (instead of playing with malloc zones) will allow > us to remove the CF dependency together with all the hacks. I'm trying > to check if this is true. > The current plan is to have dynamic runtime for both iOS (for which we > don't have any ot...

...reason? >>> Except that we still produce STV_DEFAULT. Basically we have a mode >>> where we handle GVs as if they were protected but produce a >>> STV_DEFAULT. >> >> Yes, I don’t think this is a justifiable position. We either do or do not support >> interposition of global definitions. > > I don't see why it has to be black and white like that. We have been > producing STV_DEFAULT for some time. I don't know how much we would > drop in performance if we just started not inlining some functions > just to keep them STV_DEFAULT. I’m wo...

...sly breaking overrides via LD_PRELOAD, etc.) and I don't see how virtual functions are any different. I think default LLVM behavior needs to be consistent for all inter-procedural optimizations (be it inlining, devirtualization or cloning). Maybe it's time to resurrect Hal's -fsemantic-interposition flag and use it consistently throughout compiler? Users who need GCC-like semantics will be able to employ this flag to prevent unsafe optimizations. -I

...return foo(); } > Now, compare: > clang -fPIC -O1 -S -o - test.c > gcc -fPIC -O1 -S -o - test.c > GCC will refuse to inline foo into bar, or use any information about > foo in compiling bar, because foo is exported in the dynamic symbol > table, and thus replaceable via symbol interposition. > Clang assumes that you won't do that, or that you don't care what > happens if you do. It will happily inline. And, in absense of > inlining (e.g. if foo is too long to inline), clang will deduce > function attributes about foo and rely on those in bar -- despite > that t...

No, we are not going to use mach_inject. This isn't portable and may be even harder to set up than mach_override. The new ASan runtime will use the dylib interposition and will in fact require DYLD_INSERT_LIBRARIES to work. However ASan already handles it correctly itself: if the corresponding env var is missing the app is just re-execed. Dylib interposition is supported by Apple and should work on iOS as well as Mac OS. It will also probably simplify hooking the...