[llvm-dev] [LLD] Mixing bitcode and native code

Reid Kleckner via llvm-dev llvm-dev at lists.llvm.org
Fri Mar 30 14:40:15 PDT 2018


Clang may be avoiding this problem because it will always emit
"\01__elements_exception_handler at 20" as the function name. It probably does
that for precisely this reason.

On Fri, Mar 30, 2018 at 11:55 AM Carlo Kok via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> The problem is a bitcode implementation that has a stdcall function that's
> used from native code. 1 side has _elements_exception_handler, compiled
> that would be __elements_exception_handler at 20 due to stdcall. The native
> bit has the mangled name and the linker can't find it as the bitcode
> indexes have it without mangling.
>
> I'll try to prepare a testcase when I get back in the office.
>
> Rui Ueyama <ruiu at google.com> schreef op 30 maart 2018 19:17:06 CEST:
>>
>> Mixing native and bitcode files should just work, and that happens all
>> the time, as most programs need at least crt.o (which is a precompiled
>> native object file containing startup code).
>>
>> Could you elaborate the issue a bit? It might be a bug in lld.
>>
>>
>> On Fri, Mar 30, 2018 at 3:11 AM Carlo Kok via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> On Fri, Mar 30, 2018, at 11:23, Carlo Kok via llvm-dev wrote:
>>> > When having a project that's partially bitcode and partially native
>>> code, should lld allow linking a native .o to a bitcode .o?
>>> >
>>> > specifically in my case, I've got an stdcall function in bitcode,
>>> called by native code, but it can't find the symbol (bitcode has it
>>> > unmangled, native code with _ and @20)
>>>
>>>
>>> When having thinlto enabled in both ends the same thing happens (but
>>> bitcode on both ends works fine)
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
> --
> Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn
> beknoptheid.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180330/9b815a5c/attachment.html>


More information about the llvm-dev mailing list