similar to: win32 lld Linker speed

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.

Hi, When running my own lld generated library/executable I'm getting: LD_LIBRARY_PATH=. ./ConsoleApplication347 ./ConsoleApplication347: symbol lookup error: ./ConsoleApplication347: undefined symbol: (theres nothing after undefined symbol) How can I figure out what's I'm doing wrong? Full log: https://gist.github.com/carlokok/1dd510a16e1922271b520f1c00b14656 readelf -s for

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

Rafael, here is a repro.tar to look at: https://reviews.llvm.org/F3100177 The attached foo.diff adds a print which shows the issue. ``` NAME: sleep SYMINDEX: 2 NAME: sched_yield SYMINDEX: 1 NAME: __libc_start_main SYMINDEX: 0 ``` `readelf --relocs` Shows that we create : ... 000000255110 002900000007 R_X86_64_JUMP_SLO 0000000000254410 __xstat at GLIBC_2.2.5 + 0 000000255118 001e00000007

Thanks! Unfortunately this doesn't seem to cause it, because when I fix it to match the other files (and pretty much how clang emits it:) !0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression()) !1 = !DIGlobalVariable(name: "IDispatch_UID", linkageName: "f_t2b_RemObjects_d_Elements_d_System_d_____Global.IDispatchUID", scope: !2, file: !3, type: !622, isLocal:

Yep, it's once again variable and it's type using different scopes. Is there any strong reason why you set scope for global DIDerivedType? ________________________________________ От: Carlo Kok <ck at remobjects.com> Отправлено: 21 марта 2018 г. 18:22 Кому: Evgeny Leviant; llvm-dev at lists.llvm.org Тема: Re: [llvm-dev] lld/lto/win32 crash on DIE code Thanks! Unfortunately this

I have a fairly recent LLD/LTO llvm crashing on DIE *ContextDIE = getOrCreateContextDIE(Context) being null for a (local) variable. (Context is a DICompileUnit in this case, but it's not present in MDNodeToDieMap so it returns null. callstack is: llc.exe!llvm::DwarfUnit::getOrCreateTypeDIE(const llvm::MDNode * TyNode) Line 718 C++ llvm::DwarfUnit::addType(llvm::DIE & Entity, const

Hello Carlo, I tried your reproducer and faced different problem from one you described (I'm using MacOS Sierra and lld built from trunk on Mar, 15). The crash happens when SelectionDAGBuilder::lowerInvokable tries to access EH info of this function: ms_t26_RemObjects_d_Elements_d_EUnit_d_Runnerb_RunChildrennt2a_RemObjects_d_Elements_d_EUnit_d_RunContext This happens because LLVM

Op 21-3-2018 om 10:28 schreef Evgeny Leviant: > It looks the problem lies in how your compiler generates debug info. LLVM doesn't > expect DIDerivedType scope to be an instance of DICompileUnit. Here is a quick fix: > > DIE *DwarfUnit::getOrCreateContextDIE(const DIScope *Context) { > - if (!Context || isa<DIFile>(Context)) > + if (!Context ||

I'm copying some LLD code into my codebase like this: // workaround for LLD not exposing ability to convert .def to .lib #include <set> namespace lld { namespace coff { class SymbolBody; class StringChunk; struct Symbol; struct Export { StringRef Name; // N in /export:N or /export:E=N StringRef ExtName; // E in /export:E=N SymbolBody *Sym = nullptr; uint16_t Ordinal

Ok, I've done a bit more investigation. I found the module which declares broken DIE (e54b3dc8c0536e29a65f8548b5ae7958-Global.o) and here is what I found there: !2 = !DIFile(filename: "island.windows.elements", ... ... !4 = distinct !DICompileUnit(language: DW_LANG_C99, file: !5, ... !5 = !DIFile(filename: "island.windows.elements-e54b3dc8c0536e29a65f8548b5ae7958-global",

On Wed, Jun 14, 2017 at 7:37 PM, Rui Ueyama <ruiu at google.com> wrote: > On Wed, Jun 14, 2017 at 4:24 PM, Andrew Kelley via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I'm copying some LLD code into my codebase like this: >> >> // workaround for LLD not exposing ability to convert .def to .lib >> >> #include <set> >>

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

Indeed, it's 32bits x86 and there's no .safeseh or anything like it, even readobj -coff-load-config says nothing: File: ConsoleApplication830.exe Format: COFF-i386 Arch: i386 AddressSize: 32bit Now I know what to look for, thanks! On Mon, Aug 20, 2018, at 18:46, Reid Kleckner wrote: > This is 32-bit x86, right? Sounds like the exception handler did not > appear in the /safeseh

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.

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

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

I saw this change come in yesterday: commit 572ad839e2f66eaa82ffc71b1061eb3d06a4d126 Author: Saleem Abdulrasool <compnerd at compnerd.org> Date: Thu Jun 15 20:39:58 2017 +0000 COFF: add support for lib mode usage When link is invoked with `/def:` and no input files, it behaves as if `lib.exe` was invoked. Emulate this behaviour, generating the import library from the