[PATCH] D15996: Avoid undefined behavior in LinkAllPasses.h
David Blaikie via llvm-commits
llvm-commits at lists.llvm.org
Tue Jan 12 10:13:11 PST 2016
On Tue, Jan 12, 2016 at 9:59 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>
> On Jan 12, 2016, at 8:50 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
> On Tue, Jan 12, 2016 at 8:41 AM, Mehdi Amini <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?
Alternatively: What breaks if this code is removed/these things aren't
preserved?
>
> —
> Mehdi
>
>
>
>
>> On Jan 12, 2016, at 8:02 AM, David Blaikie via llvm-commits <
>> 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> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> 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/887f508b/attachment.html>
More information about the llvm-commits
mailing list