similar to: [LLD] Mixing bitcode and native code

Displaying 20 results from an estimated 10000 matches similar to: "[LLD] Mixing bitcode and native code"

2018 Mar 30
2
[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
2018 Mar 30
0
[LLD] Mixing bitcode and native code
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.
2018 Mar 30
0
[LLD] Mixing bitcode and native code
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)
2018 Mar 30
1
[LLD] Mixing bitcode and native code
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
2018 Apr 03
0
[LLD] Mixing bitcode and native code
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
2018 Mar 30
2
Proper way to do thinlto (from code)
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:
2018 Mar 30
1
Proper way to do thinlto (from code)
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
2018 Mar 30
0
Proper way to do thinlto (from code)
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
2018 Mar 29
1
win32 lld Linker speed
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
2017 May 30
2
Missing symbol __executable_start on Android when linking with LLD
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
2019 May 08
2
taskpool exhaustion in lld/wasm
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
2018 Jul 30
3
lld/mach-o x86_64 asserts
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
2019 May 08
2
taskpool exhaustion in lld/wasm
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
2017 May 30
2
Missing symbol __executable_start on Android when linking with LLD
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: >
2018 Jul 17
2
lld/mach-o x86_64 asserts
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?
2016 Jun 07
2
lld/x86_64 linux elf invalid link_map
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
2017 Feb 22
2
[lld] elf linker creates undefined empty symbol
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
2017 Feb 21
3
[lld] elf linker creates undefined empty symbol
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.
2009 Dec 23
1
[LLVMdev] MinGW llvm-gcc --enable-stdcall-fixup error
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
2019 Jun 07
2
LLD/Link find out what triggers 80mb exe
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: >> __ >>