search for: fsemant

...r" <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...

...ute__((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 >&...

...xternal or 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 def...

...s mercilessly 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

...current behavior is the most-useful behavior and we should keep the current behavior (at least as a default). I do understand, however, that there are valid use cases for ELF interposition and places where we should allow it (e.g. when compiling certain system libraries). GCC recently added a flag -fsemantic-interposition/-fno-semantic-interposition, where using -fno-semantic-interposition provides Clang/LLVM's behavior of assuming that ELF interposition will not be used. It has been suggested that, to be self consistent, LLVM should emit global symbols with protected ELF visibility in cases wh...

...des 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. > -fsemantic-interposition controls whether the compiler may assume that symbols are not interposed, and it has nothing...

...the most-useful behavior > and we should keep the current behavior (at least as a default). I do > understand, however, that there are valid use cases for ELF interposition > and places where we should allow it (e.g. when compiling certain system > libraries). GCC recently added a flag -fsemantic-interposition/-fno-semantic-interposition, > where using -fno-semantic-interposition provides Clang/LLVM's behavior of > assuming that ELF interposition will not be used. > > It has been suggested that, to be self consistent, LLVM should emit global > symbols with protected ELF...

...the most-useful behavior > and we should keep the current behavior (at least as a default). I do > understand, however, that there are valid use cases for ELF interposition > and places where we should allow it (e.g. when compiling certain system > libraries). GCC recently added a flag -fsemantic-interposition/-fno-semantic-interposition, > where using -fno-semantic-interposition provides Clang/LLVM's behavior of > assuming that ELF interposition will not be used. > > It has been suggested that, to be self consistent, LLVM should emit global > symbols with protected ELF...

...inked 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/gcc-5.3.0/gcc/Optimize-Options.html#index-fsemantic-interposition-972> Okay. The way we should be thinking about this is that -fno-semantic-interposition is the default rule on Clang. Now, if we fully embrace that by making symbols protec...

> 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

----- Original Message ----- > From: "James Y Knight" <jyknight at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Sanjoy Das" <sanjoy at playingwithpointers.com>, "llvm-dev" > <llvm-dev at lists.llvm.org> > Sent: Monday, February 29, 2016 9:31:24 AM > Subject: Re: [llvm-dev] Possible soundness issue with

...much more aggressive devirtualization. Note that by default, unlike GCC, LLVM is liberal on visibility-constrained optimizations. In particular it freely performs inlining, IPA and cloning on them (see https://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html which also suggested adding -fsemantic-interposition to actually respect visibility in optimizations). It's unclear why devirtualization should behave differently than other optimizations (at least by default). -I

...>>> In summary, I think it is important that >>> >>> * a __attribute__((visibility("protected"))) maps to STV_PROTECED >>> * by default a decl with no attributes maps to STV_DEFAULT >> >> It’s not really my place to decide whether or not -fsemantic-interposition should be >> the default, so I’ll leave this up to others to debate. >> >> My instinct is that interposition is not actually important to very many people, >> and that the people who rely on it won’t really mind having to opt in. We have >> also been...

On Feb 26, 2016 8:50 PM, "Hal Finkel" <hfinkel at anl.gov> wrote: > *From: *"James Y Knight via llvm-dev" <llvm-dev at lists.llvm.org> > *To: *"Sanjoy Das" <sanjoy at playingwithpointers.com> > *Cc: *"llvm-dev" <llvm-dev at lists.llvm.org> > *Sent: *Thursday, February 25, 2016 1:41:43 PM > *Subject: *Re: [llvm-dev]

Please send any comments. As mentioned at the end I will follow up with some patches as soon as they are cleaned up and I create some test cases. RFC: Safe Whole Program Devirtualization Enablement =================================================== High Level Summary ------------------ The goal of the changes described in this RFC is to support aggressive Whole Program Devirtualization without