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

[David Blaikie via llvm-commits]

On Tue, Jan 12, 2016 at 10:28 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:

>
> 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>
> 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?
>
>
> 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).
>

Right, but that's my point - if there are real call sites somewhere,
they'll be kept, if not, they won't. I'm wondering/trying to understand why
the real uses are insufficient/not working, to better understand what we're
dealing with.

But if we ignore that - then, yes, maybe calling printf on the function
pointers may be sufficient to escape them beyond any analysis? It's all a
bit of an arms race, though...


>
> 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> 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/aa63635b/attachment.html>