search for: interposable

...age for example. > > > That said, do you think we should take the opportunity to split out > > a > > bit for interposability so that we can kill off the *_odr linkage > > variants? Today's non-ODR weak functions would look more like this: > > > define weak interposable void @foo() { ret void } > > > We could probably preserve bitcode compatibility by continuing to > > use > > the old combined linkage encoding. This is useful because we want > > the old weak to decode as weak+interposable and the old weak_odr to > > decode as wea...

...ould imagine having "external / external_odr" linkage for example. That said, do you think we should take the opportunity to split out a bit for interposability so that we can kill off the *_odr linkage variants? Today's non-ODR weak functions would look more like this: define weak interposable void @foo() { ret void } We could probably preserve bitcode compatibility by continuing to use the old combined linkage encoding. This is useful because we want the old weak to decode as weak+interposable and the old weak_odr to decode as weak. Some more prior discussion: https://reviews.llvm.org...

On Mon, Feb 22, 2016 at 11:18 PM, Chandler Carruth <chandlerc at gmail.com> wrote: >> # step A: Introduce an `interposable` function attribute >> >> We can bike shed on the name and the exact specification, but the >> general idea is that you cannot do IPA / IPO over callsites calling >> `interposable` functions without inlining them. This attribute will >> (usually) have to be used on fu...

> On Jun 14, 2017, at 2:47 PM, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On 15 Jun 2017, at 6:50 AM, Louis Gerbarg <lgerbarg at apple.com <mailto:lgerbarg at apple.com>> wrote: >> >>> >>> On Jun 6, 2017, at 4:08 PM, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at

...outside of the defining library might be different from the pointer obtained within the defining library). As a result, making this change might be practically prohibited (even if it makes sense in theory). Proposal: 1. Add a new linkage type, interposible, which is like external except that isInterposableLinkage will return true (thus preventing inlining, IPA, etc.). This is similar to weak linkage, in a sense, except that such symbols are never discarded and are not marked as weak for linking, etc. 2. Add -fsemantic-interposition/-fno-semantic-interposition to Clang. Default to -fno-semantic-inte...

Assuming everyone is on the same page, here's a rough high level agenda: # step A: Introduce an `interposable` function attribute We can bike shed on the name and the exact specification, but the general idea is that you cannot do IPA / IPO over callsites calling `interposable` functions without inlining them. This attribute will (usually) have to be used on function bodies that can deoptimize (e.g. has...

...defined by another object inside the same shared library -- but not in this file -- and that calls should be made directly to the symbol, not through the PLT. That is, we have: - The default for llvm functions is that if the definition is visible, it is assumed to be the one that will be used (not interposable), and optimizations can assume properties of the function, and it can be called directly without going through the PLT. (But addressof still needs to be careful). - If the definition is NOT visible, the default is to assume the symbol MIGHT be external to the shared object, and needs to go through...

On Tue, Feb 23, 2016 at 10:55 AM, Chandler Carruth <chandlerc at gmail.com> wrote: >> Part of the challenge here is to specify the attribute in a way that >> allows inlining, but not IPA without inlining. In fact, maybe it is >> best to not call it "interposable" at all? > > > Yea, this is something *very* different from interposable. GCC and other > compilers that work to support symbol interposition make specific efforts to > not inline them in specific ways (that frankly I don't fully understand, as > it doesn't seem to be...

----- 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

Hi there was a mail a while back on this list about using the LD_PRELOAD feature on Solaris in order to override the location of nsswitch.conf for smbd so only it would use winbindd. I did some digging and came up with the code at the bottom of this mail ( I've overridden every file open call I could find, but I think it's only the _open() call which is actually necessary ). Initial

I''d like to see if we can use DTrace to as the kernel implementation of the BSD systrace security policy system (http://www.systrace.org). I don''t really want to port systrace to Solaris because I think with DTrace we already have all the necessary in kernel hooks to do this. With systrace you express things like: "httpd can bind to port 80 but not any other port, it

...tic-interposition is the default rule on Clang. Now, if we fully embrace that by making symbols protected by default, we will break somebody out there who’s relying on interposition despite our poor support for it. Therefore, we need to have a story for how to unbreak them. For a small number of interposable symbols, it’s reasonable for us to tell them to use __attribute__((weak)). However, some people might have a ton of symbols they interpose, and other people will complain about us doing things differently from GCC; for those people, we will need to support an explicit -fsemantic-interposition opti...

I want to create my own "[" function (for use on vectors, matrices, arrays, etc.), which calls the stock R "[", does some additional work, and then finally returns the modified result. But, how do I properly call the stock R "[" function? It takes a varying number of positional arguments, and its R-level closure is just: .Primitive("[") It's

+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 issues with the allocator which

> On Jun 6, 2017, at 4:08 PM, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Folks, > > I’m working on a port of musl libc to macos (arch triple is “x86_64-xnu-musl”) to solve some irreconcilable issues I’m having with libSystem.dylib. I don’t want to use glibc for various reasons, mainly because I want to static link. I have static PIE + ASLR working

> 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

Hi- I am running Samba 2.2.5 on Solaris 8 with winbind and pam configured. I have the following in my nsswitch.conf: passwd: files winbind group: files winbind Now local users on the Solaris 8 machine cannot change there password using the passwd command: Here is the sample output: # passwd michasp1 Enter new password: Enter new password again: Supported configurations for passwd

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

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]

Howdy. I have a application I'm developing where I need to encrypt the data inside an OGG stream. I will be using a regular block cypher (AES, or others... configurable); and I would like to encrypt the pages in an OGG stream. I'm thinking that if I sit my decrypter in between the reading application and the encrypted file, you should be able to use all the normal seeking