[PATCH] D15996: Avoid undefined behavior in LinkAllPasses.h

Mehdi Amini via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 12 10:28:46 PST 2016


> On Jan 12, 2016, at 10:13 AM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Tue, Jan 12, 2016 at 9:59 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
> 
>> On Jan 12, 2016, at 8:50 AM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote:
>> 
>> 
>> 
>> On Tue, Jan 12, 2016 at 8:41 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
>> You need to be careful that an LTO build won’t inline and eliminate this.
>> 
>> fair - but these calls, if they'd executed, would've been totally bogus, right? (they would've crashed/null dereferenced, etc)
>> 
>> So somehow this code is live without it actually executing.
> 
> Sure it won’t execute because of the guard:   if (std::getenv("bar") != (char*) -1) return;
> 
> But my point was more than taking the address and not doing anything with it is not the same as calling a function, I mentioned it because I’m not sure what you had in mind to make sure the pointer always escape (printf like Tobias suggested should work).
> 
>> 
>> To come back to the underlying issue: What is it we're trying to solve here? What entities are we trying to preserve & why are more traditional/normal ways of preserving them insufficient? (sorry if this is too much of a derailment/the rest  of you have enough context here, feel free to go on without me ;))
> 
> What is a “more traditional/normal way of preserving” symbols? Export lists?
> 
> Well, at the most basic level - if this code is needed it must be called from somewhere, why is that insufficient to ensure it is linked into the binary?

OK, but that’s one level up, assuming `ForcePassLinking()` is called, now of do you make sure it includes all the other symbols we want? 
There is no problem with the `llvm::createXXXXPass()` calls, but this patch was about two "more complex" symbols:

((llvm::Function*)nullptr)->viewCFGOnly();
((llvm::RegionPass*)nullptr)->runOnRegion((llvm::Region*)nullptr, RGM);

They require an object that you don’t have (and llvm::RegionPass has a pure virtual function so it can’t be created easily).

> Alternatively: What breaks if this code is removed/these things aren't preserved?

I don’t know for these two in particular, I guess the second one was for Polly (Tobias?).

— 
Mehdi

> 
> 
>> 
>>> On Jan 12, 2016, at 8:02 AM, David Blaikie via llvm-commits <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>> wrote:
>>> 
>>> Do you need to call anything? Could you just take the address of the function and return it, stuff it in a global, or otherwise escape it?
>>> 
>>> On Tue, Jan 12, 2016 at 12:02 AM, Dimitry Andric via llvm-commits <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>> wrote:
>>> dim added a subscriber: grosser.
>>> 
>>> ================
>>> Comment at: include/llvm/LinkAllPasses.h:191
>>> @@ -190,3 +196,3 @@
>>>        llvm::RGPassManager RGM;
>>> -      ((llvm::RegionPass*)nullptr)->runOnRegion((llvm::Region*)nullptr, RGM);
>>>        llvm::AliasSetTracker X(*(llvm::AliasAnalysis*)nullptr);
>>> ----------------
>>> @grosser, you originally added this part in rL117263 ("Reference RegionPass to stop it being eliminated"), do you have any suggestions? If the goal is to to unsure RegionPass.cpp is linked in, I think we can call `RegionPass::createPrinterPass()` instead.
>>> 
>>> 
>>> http://reviews.llvm.org/D15996 <http://reviews.llvm.org/D15996>
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits>
>>> 
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits>
>> 
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160112/e4ac5626/attachment.html>


More information about the llvm-commits mailing list