similar to: [LLD] Mixing bitcode and native code

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

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.

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)

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

Seems my problem was the reverse; the definition did NOT have stdcall properly set; which is why i wasn't found. Setting that and everything worked. Thanks for the help. On Fri, Mar 30, 2018, at 23:40, Reid Kleckner wrote: > 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

I'm using llvm-c (but if needed can call c++ stuff too if nedeed); what's the proper way to emit bitcode with thinlto info so the linker can parallelize ?I'm currently using: unwrap(PMB)->PrepareForThinLTO = b; on the pass manager builder, but that doesn't seem to be enough? -------------- next part -------------- An HTML attachment was scrubbed... URL:

Thanks! I'll create a wrapper for WriteBitcodePass. Do I still need the PrepareForThinTLO pass or is the writeBitCodePass enough? On Fri, Mar 30, 2018, at 10:02, Peter Collingbourne wrote: > You need to make sure that your bitcode file has a module summary > index. You can do that either by creating a WriteBitcodePass with > EmitSummaryIndex set to true or by calling

You need to make sure that your bitcode file has a module summary index. You can do that either by creating a WriteBitcodePass with EmitSummaryIndex set to true or by calling WriteBitcodeToFile with a module summary index that you created yourself. It doesn't look like either of those options are hooked up to the c API, though. Peter On Fri, Mar 30, 2018, 00:50 Carlo Kok via llvm-dev

I've got a customer project that emits a 18 MB .exe and 9 MB .exe.pdb; It takes about 6 minutes to link on their system, 2 minutes to link on mine (this a regullar lld -flavor link /opt:lldlto=0). the input is about 61mb of bitcode files (originally about 2100 object files) with debug info (both pdb and dwarf get emitted) stored in 5 .lib files, compiled with -O0 but with thin-lto (without

When linking a project with lld, the android libc links to __executable_start which isn't defined when linking with lld (tried on x86), but is when linking with gnu ld it seems. I tried: .globl __executable_start __executable_start = __ehdr_start as a workaround but seems to be ignored. Anyone know a better workaround? Thanks, -- Carlo Kok RemObjects Software

It's a wasm testcase that ends up with a 1 mb executable; after 15 minutes I killed it, it doesn't do anything (note that it's waiting on a conditional variable in ALL threads) On Wed, May 8, 2019, at 14:32, Brian Cain wrote: > Are you sure it's not just taking "a long time"? If that build machine doesn't have enormous amounts of memory you could end up with a

Sorry, I was thinking to review the test but didn't. Is this test complete? It does invoke lld, but it didn't verify its output. On Mon, Jul 30, 2018 at 2:03 PM Andrew Kelley <superjoe30 at gmail.com> wrote: > Ping Rui. Is there anything else that needs to be done on this patch? > > On Tue, Jul 17, 2018 at 6:58 AM, Carlo Kok via llvm-dev < > llvm-dev at

On a 12" MacBook (2017) with 2 cores I get lld/wasm to be stuck in: https://gist.githubusercontent.com/carlokok/1a14e7ed3dbbd54511e1f0b3a7d684ff/raw/19267560b584ca42cc66f44f508df5b34102d803/thread%2520for%2520waiting It seems the outer for loop exhausts the thread pool, and the inner ones trigger a new parallel for which never finishes because the pool is full. Is this a bug or am I

Android libc casts its address to the elf header type. So I think start of text? Rafael Avila de Espindola <rafael.espindola at gmail.com> schreef op 30 mei 2017 20:51:19 CEST: >It is missing from lld. > >Do you know what it should point to? The first executable PT_LOAD? > >Thanks, >Rafael > >Carlo Kok via llvm-dev <llvm-dev at lists.llvm.org> writes: >

Got it. Attached are both the testcase & the fix. On Tue, Jul 17, 2018, at 12:06, Carlo Kok via llvm-dev wrote: > On Wed, Jul 11, 2018, at 16:45, Davide Italiano wrote: > > On Tue, Jul 10, 2018 at 10:12 PM Carlo Kok via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > > > > > > That sounds quite reasaonable; how does one usually go about doing that?

I'm having a curious issue with LLD/x86_64 linux/elf (Ubuntu 14.04); Where the l_addr of the link_map is invalid when linked with lld, but is fine with gnu ld. I'm using the libgc (boehm) code which when initializing reads the DYNAMIC/DEBUG link_map data, and crashes because the l_addr field has value out of readable memory. The strange this is that it happens only on some linux

On Tue, Feb 21, 2017 at 2:05 PM, Rafael Avila de Espindola via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Carlo Kok <ck at remobjects.com> writes: > > > On 2017-02-21 20:33, Rafael Avila de Espindola wrote: > >>> Input files: > >>> https://www.dropbox.com/s/8yn3dggx05atn47/binLinux.zip?dl=0 > >> > >> If you pass --reproduce

On 2017-02-21 20:33, Rafael Avila de Espindola wrote: >> Input files: >> https://www.dropbox.com/s/8yn3dggx05atn47/binLinux.zip?dl=0 > > If you pass --reproduce foo.tar to lld it will create a foo.tar file > with all that is needed to reproduce the link. > > Can you also share how you created the various .o files? If so I might > be able to try reducing the issue.

When attempting to compile this simple testing tool http://github.com/oneclick/rubyinstaller/blob/fake/resources/tools/fakeruby.c I get the following: C:\Users\Jon\Documents\CDev\sandbox>llvm-gcc -Wall -o fakeruby.exe fakeruby.c Warning: resolving _GetModuleHandleA by linking to _GetModuleHandleA at 4 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable

I did try that yes. Didn't seem to make any difference (still 80ishmb) On Fri, Jun 7, 2019, at 15:29, David Major wrote: > Just to double check: are you calling lld-link with `-opt:ref`? It may or may not be enabled by default, depending on other flags. > > > On Fri, Jun 7, 2019 at 8:26 AM Carlo Kok via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> __ >>