On Tue, Mar 16, 2010 at 6:57 PM, Chris Lattner <clattner at apple.com> wrote:> > The "tail" marker has a very specific description in LLVM IR: it says that the caller does not access the callee's stack: > http://llvm.org/docs/LangRef.html#i_callAh that makes more sense. Thanks for the pointer.> > 2) When I instrument the code using my opt pass, none of the instrumentation functions in the callee get called, leading me to believe that some funny business is going on. > I don't know about this.That is because I did not give you enough information :). I realized that the callee was linkonce_odr, and so the function body that I was instrumenting was not making its way into the final executable. This is why I was not seeing my debug info printed. So if I am looking at a CallInst, and want to know if the callee is going to be instrumented by my pass, I can check F->isWeakForLinker(), where F is the called function. But this just tells me when the function definition *may* be replaced. I want to know precisely when the CallInst is a call to a function that I am going to instrument as part of my pass (ignore indirect invocations for the moment). Obviously I could do an initial pass and build an explicit list of such functions. But is there an easier way by just looking at the Function object? I guess I am looking for something like F->IsGoingToGetReplacedAtLinkTime(). Actually, that seems like it is probably impossible to resolve during the pass.
Hi Scott,> So if I am looking at a CallInst, and want to know if the callee is > going to be instrumented by my pass, I can check F->isWeakForLinker(), > where F is the called function. But this just tells me when the > function definition *may* be replaced. I want to know precisely when > the CallInst is a call to a function that I am going to instrument as > part of my pass (ignore indirect invocations for the moment). > Obviously I could do an initial pass and build an explicit list of > such functions. But is there an easier way by just looking at the > Function object? > > I guess I am looking for something like > F->IsGoingToGetReplacedAtLinkTime(). Actually, that seems like it is > probably impossible to resolve during the pass.I don't really understand what you are asking. In general a function with weak linkage may or may not be replaced by another at link time, but you can't tell before link time. For example, suppose a function called F (I will refer to this as F1) has weak linkage. If at link time you link with another object file that also defines a function called F (I will refer to this as F2) but not with weak linkage, then F1 will be discarded and F2 is what will end up in the executable. On the other hand, suppose F2 also has weak linkage, then I think one of F1/F2 is chosen essentially randomly. Finally, if at link time no other object file defines a function called F then F1 will be used. So what happens is determined by what the user passes to the linker, and as such is not known at compile time. A philosophical remark: if you could tell at compile time which function bodies will be in the final executable, then there would be no point in having weak linkage: if you can tell that the function body is not going to be used then you might as well throw it away (i.e. replace with a declaration) and not bother optimizing it; on the other hand, if you are sure that it is going to be used then you might as well give it strong linkage. Ciao, Duncan.
> I don't really understand what you are asking. In general a function with > weak linkage may or may not be replaced by another at link time, but you > can't tell before link time. For example, suppose a function called F (I > will refer to this as F1) has weak linkage. If at link time you link with > another object file that also defines a function called F (I will refer to > this as F2) but not with weak linkage, then F1 will be discarded and F2 is > what will end up in the executable. On the other hand, suppose F2 also has > weak linkage, then I think one of F1/F2 is chosen essentially randomly. > Finally, if at link time no other object file defines a function called F > then F1 will be used. So what happens is determined by what the user passes > to the linker, and as such is not known at compile time. > > A philosophical remark: if you could tell at compile time which function > bodies will be in the final executable, then there would be no point in > having weak linkage: if you can tell that the function body is not going > to be used then you might as well throw it away (i.e. replace with a > declaration) and not bother optimizing it; on the other hand, if you are > sure that it is going to be used then you might as well give it strong > linkage.OK this makes sense, thanks for the example and the general comment. Let me be a bit more clear about my problem. I am instrumenting code with an opt pass. If I come across a CallInst, the way I instrument it depends on whether the body of the callee will also be instrumented. If the callee is some function in, say, a dynamically loaded share library, it won't be instrumented (because I am not running the library through my pass). Previously, I assumed that as long as I could see the function definition in the module, it was safe to assume that I was going to instrument it. But I recently came across examples where the function definition from a dynamically loaded library was brought in and assigned linkonce_odr. I would instrument that definition, but then that definition was not used at link time, so my instrumented code was broken. So I actually don't care which version of the function gets finally linked, but I do care whether or not it is a version that actually runs through my opt pass. Does that make more sense? However, from your philosophical comment, it seems like in general this is not going to be possible. It also sounds like I need to educate myself a bit more about linkage, beyond just the LLVM docs. Thanks, Scott