similar to: Reducing confusion around isUndefined()

I've got a patched LLD 5.0.0 like this: diff --git a/deps/lld/COFF/Driver.cpp b/deps/lld/COFF/Driver.cpp index 854c3e69..8bab1c11 100644 --- a/deps/lld/COFF/Driver.cpp +++ b/deps/lld/COFF/Driver.cpp @@ -1030,7 +1030,7 @@ void LinkerDriver::link(ArrayRef<const char *> ArgsArr) { if (!Args.hasArgNoClaim(OPT_INPUT)) { fixupExports(); createImportLibrary(/*AsLib=*/true); -

I believe that LLD is not supposed to call exit on success when you call lld::coff::link. >From downstream fork of LLD: https://github.com/zig-lang/zig/commit/41da9fdb69065082f57c604b12eb02ca166cb18d diff --git a/lld/COFF/Driver.cpp b/lld/COFF/Driver.cpp index 854c3e69098..8b17f039870 100644 --- a/lld/COFF/Driver.cpp +++ b/lld/COFF/Driver.cpp @@ -1030,7 +1030,7 @@ void

I think you want to call freeArena() before returning from lld::coff::link. On Sun, Oct 15, 2017 at 6:57 PM, Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I believe this line is the culprit: > > COFF/Driver.cpp:102: > make<std::unique_ptr<MemoryBuffer>>(std::move(MB)); // take ownership > > Patch forthcoming. > > > On Sun, Oct

Correct, I am using libCOFF, libELF, and libMACHO all as a library. Ideally all cases would return and report an error and clean up memory, etc, instead of calling exit. However this is sufficient for my needs for now. It is ok for LLD to crash if I supply an invalid command line argument, I won't do that. On Thu, Aug 31, 2017 at 5:47 PM, Rui Ueyama <ruiu at google.com> wrote: >

Compiling the IR code at http://pastebin.com/hSwdLdD0 for target triple x86_64-apple-macosx fails with : assert(Symbol->isUndefined() && "Cannot define a symbol twice!"); `anon'::MCMachOStreamer::EmitLabel(llvm::MCSymbol * Symbol) llvm::DwarfDebug::emitDebugInfo() Line 1752 + 0x3c bytes C++ llvm::DwarfDebug::endModule() Line 865 C++

I have made some further investigation. My conclusion is that GNU ld does not do better than lld. Making the --defsym behavior ideal is difficult in the current framework. GNU ld has some unintended behaviors. ld.bfd a.o --defsym 'd=foo' --gc-sections -o a => GNU ld retains .text_foo ld.bfd a.o --defsym 'd=foo+3' --gc-sections -o a => GNU ld drops .text_foo ld.bfd a.o

Hi, What is the best way to debug an llc crash using bugpoint? I am getting the following crash that I would like to reduce llc: /home/vadve/aggarwa4/llvm29/llvm-2.9/lib/MC/MCAsmStreamer.cpp:273: virtual void<unnamed>::MCAsmStreamer::EmitLabel(llvm::MCSymbol*): Assertion `Symbol->isUndefined() && "Cannot define a symbol twice!"' failed. 0 llc

Do something like this: bugpoint -run-llc <bitcode file> --tool-args -- <llc arguments> Cameron On May 23, 2011, at 1:33 PM, Arushi Aggarwal wrote: > Hi, > > What is the best way to debug an llc crash using bugpoint? > > I am getting the following crash that I would like to reduce > > llc: /home/vadve/aggarwa4/llvm29/llvm-2.9/lib/MC/MCAsmStreamer.cpp:273:

If you call lld::coff::link twice, the second time gives this backtrace: msvcp140d.dll!00007ffc35830806() Unknown > zig.exe!std::_Debug_pointer<lld::coff::Chunk * __ptr64 const>(lld::coff::Chunk * const * _Ptr, const wchar_t * _File, unsigned int _Line) Line 926 C++ zig.exe!std::_Debug_range2<lld::coff::Chunk * __ptr64 const * __ptr64>(lld::coff::Chunk * const *

I encountered a segfault when using lld to cross-compile for Windows (+MinGW) from Linux. The problem happens with objects built by gcc. The problem is that ObjFile::CreateRegular considers a PendingComdat to be valid (and later causes an illegal pointer dereference). The following patch fixes the crash: diff --git a/COFF/InputFiles.cpp b/COFF/InputFiles.cpp index 9e2345b0a..f47d612df 100644

+Rui and Peter On Wed, Jul 25, 2018 at 8:34 AM, Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Here's a fix: > > --- a/lld/COFF/Driver.cpp > +++ b/lld/COFF/Driver.cpp > @@ -72,6 +72,9 @@ bool link(ArrayRef<const char *> Args, bool CanExitEarly, > raw_ostream &Diag) { > exitLld(errorCount() ? 1 : 0); > > freeArena(); > +

Can you upload a reproducer? You can create it using the /linkrepro flag. Peter On Thu, Jun 7, 2018 at 2:50 PM, Reid Kleckner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > GCC does comdats completely differently from the spec. Since you contacted > me about this off of the mailing list, I started investigating what they > do, and it is completely different. It's

The current implementation of llvm::Mangler does not check if a symbol name exists before mangling. This can cause problems if the mangled name aliases another symbol in the IR. For example, consider the following: @"a(b" = addrspace(1) global float 1.0 @"a_28_b" = addrspace(1) global float 1.0 If I run this through the x86 backend, I get: llc:

Hi, I'm embarrassed that I can't figure this out... I have a compiler that outputs my module in either .s assembly format or .obj binary format, either one works just fine. But if I try to output both of them by adding passes, LLVM throws an Assert: void WinCOFFStreamer::EmitLabel(MCSymbol *Symbol) { assert(Symbol->isUndefined() && "Cannot define a symbol

Hi all, I think that I came somewhat closer to a solution for splitting a MachineBasicBlock for a PSEUDO_CALL_R instruction and having a label to the new MBB: For following piece of code: --- typedef int callme_t(int a, int b); callme_t* c01; int foo(int a, int b) { return c01(a,b); // MachineBasicBlock will be split at call instruction } --- I have initially following correspondence: BB1

Hi, I am wondering if someone can guide me in adding metadata to IR which already contains some metadata. I am trying to add dbg.declare inst for a local variable I added to a function. I used the DIBuilder to build a DIVariable. When I try to compile llc fails with following message. llc: MCAsmStreamer.cpp:273: virtual void<unnamed>::MCAsmStreamer::EmitLabel(llvm::MCSymbol*): Assertion

Hi Chris, your commit 103140 broke PR397 for llvm-gcc (in LLVM 2.9) and dragonegg. In the PR, asm renaming creates two linkonce functions with the same asm name (in the IR they are @"\01lstat64" and "@lstat64". What used to happen is that they were both output to the assembler file, both with the name lstat64, exactly like GCC does. The assembler and linker are perfectly

Hi Daniel, attached is a patch that pushes most of the object file specific parsing out of AsmParser and down into MachOAsmParser. This was done as a cleanup for the ELF work. I know that you're not happy with this approach, particularly the fact that as we add more object file formats and assembler dialects, it's going to cause a class explosion. But I was hoping that we could use this

On Wed, 4 Dec 2019 at 07:05, Fāng-ruì Sòng <maskray at google.com> wrote: > > On Tue, Dec 3, 2019 at 7:02 PM Shoaib Meenai via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > LLD treats any symbol referenced from a linker script as a GC root, which makes sense. Unfortunately, it also processes --defsym as a linker script fragment internally, so all target

Note that this does not fix gettext for app, that will be done separately in another patch as F10/F11 require different setups for that. In the meantime gettext works if manually changed in environment.rb to gettext_rails instead of gettext/rails Signed-off-by: Jason Guiditta <jason.guiditt at gmail.com> --- src/app/controllers/application.rb | 200 --------