[llvm] r240010 - Update LLVM bindings after r239940. Apparently these aren't included in

Reid Kleckner rnk at google.com
Mon Jul 6 16:04:15 PDT 2015


On Thu, Jun 18, 2015 at 6:42 PM, Eric Christopher <echristo at gmail.com>
wrote:
>
> On Thu, Jun 18, 2015 at 6:35 PM David Majnemer <david.majnemer at gmail.com>
> wrote:
>
>> On Thu, Jun 18, 2015 at 6:19 PM, Sean Silva <chisophugis at gmail.com>
>> wrote:
>>>
>>> On Thu, Jun 18, 2015 at 5:26 PM, Eric Christopher <echristo at gmail.com>
>>> wrote:
>>>
>>>> Hi Sean,
>>>>
>>>> Daniel is a few time zones ahead and likely won't get this, probably
>>>> best if you do.
>>>>
>>>> That said, we should also talk to David (on the to: line) who put in
>>>> the personality function change in the first place :)
>>>>
>>>
>>> Yeah. David, is there something reasonable we can do here to avoid
>>> breaking compatibility? It looks like this just moved from the instruction
>>> to the function. Could we set it on the function instead? (From your commit
>>> message on r239940, it seems like any existing correct code already had all
>>> of the personality functions within a given function the same, so can we
>>> just set the landingpad on the function?)
>>>
>>
>> We could do that but it would be inconsistent with what we have done with
>> linkage.  For example: LLVMSetLinkage with LLVMDLLImportLinkage doesn't
>> call setDLLStorageClass for you.
>>
>> I wasn't under the impression that LLVMBuildLandingPad was part of a
>> stable interface.  Do we have any documentation or comments to that
>> effect?  I couldn't find anything official looking which stated whether or
>> not the C bindings are supposed to be link, source or otherwise backwards
>> compatible.
>>
>>
>
> It's been a long standing part of the project (though, like you, I
> couldn't find the explicit documentation) that the C API is source
> compatible and that we try very hard to keep it as such. You'll notice lots
> of places we've done odd commits to try to do so.
>

IMO we should just make LLVMBuildLandingPad() set the personality of the
parent function. Any frontend using the C API will just keep working. It
might break more sophisticated users of the C API, but so be it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150706/61cea129/attachment.html>


More information about the llvm-commits mailing list