search for: coff

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_range...

+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(); > + ObjFile::Instances.clear(); > + ImportFile::Instances.clear()...

I am getting the following on 'make install' on Cygwin both on debug and release builds :- llvm[3]: Installing Release /home/ang/llvm-coff/bin/llvmc.exe make[3]: Leaving directory `/home/ang/build/llvm-coff/tools/llvmc/driver' make[2]: Leaving directory `/home/ang/build/llvm-coff/tools/llvmc' make[1]: Leaving directory `/home/ang/build/llvm-coff/tools' make[1]: Entering directory `/home/ang/build/llvm-coff/runtime' mak...

...t 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 --- a/COFF/InputFiles.cpp +++ b/COFF/InputFiles.cpp @@ -229,11 +229,11 @@ Symbol *ObjFile::createRegular(COFFSymbolRef Sym) { if (Sym.isExternal()) { StringRef Name; COFFObj->getSymbolName(Sym, Name); - if (SC...

Right now, we have: In COFF.h: class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... }; }; In windows.h: #define IMAGE_FILE_MACHINE_UNKNOWN 0 * If you first include COFF.h and then windows.h, COFF::IMAGE_FILE_MACHINE_UNKNOWN will be preprocessed into COFF:0. * If you first include Windows....

...t really part of the C ABI. > > Anyway, if we want to be C++ ABI compatible with GCC+binutils on Windows, > there will be a lot of work to do. It's not a small patch here or there, it > requires more research. We should discuss it in full. > > I support recovering from invalid COFF files to avoid crashes in any way > we can, though, so this patch might still be good. > > On Thu, Jun 7, 2018 at 2:44 PM Pirama Arumuga Nainar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I encountered a segfault when using lld to cross-compile for Windows &g...

...futures/futures.unique_future/wait_until.pass.cpp libomp :: api/omp_get_wtime.c libomp :: tasking/kmp_task_reduction_nest.cpp libunwind :: alignment.pass.cpp libunwind :: libunwind_01.pass.cpp libunwind :: libunwind_02.pass.cpp libunwind :: unw_getcontext.pass.cpp lld :: COFF/alternatename.test lld :: COFF/ar-comdat.test lld :: COFF/arm-thumb-branch-error.s lld :: COFF/arm-thumb-branch20-error.s lld :: COFF/arm64-dynamicbase.s lld :: COFF/arm64-import2.test lld :: COFF/arm64-magic.yaml lld :: COFF/arm64-relocs-imports.test lld :: COFF/arm...

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 forthcomin...

On Thu, Feb 8, 2018 at 10:43 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 7 Feb 2018, at 21:51, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: >> >> There's been a lot of merges since rc1, and hopefully the tests are in >> a better state now. >> >> 6.0.0-rc2 was just tagged, after r324506. >> >>

Folks, I want to automate some graphing using ggplot. Here is my code graphChargeOffs2<-function(coffs) { ggplot(coffs, aes(levels)) dataNames<-names(coffs)[!names(coffs) == "levels"] for(i in dataNames) { thisData<-coffs[[i]] last_plot() + geom_line(aes(y = thisData, colour = i)) } last_plot() + ylab("Total Chargeoffs") } coffs is a data.frame. I get t...

The new linker is quickly becoming more than just an experiment. 64-bit COFF linker is mostly feature complete, and now we are having a direct translation of the COFF linker for ELF. Historically LLD has been suffered by over-designing and over-engineering. I don't want to repeat that again in the new codebase, so I'd like to be an owner of the new linkers (both fo...

On Aug 28, 2013, at 7:05 PM, Virgile Bello <virgile.bello at gmail.com> wrote: > Right now, we have: > In COFF.h: > class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... }; }; > In windows.h: > #define IMAGE_FILE_MACHINE_UNKNOWN 0 > > * If you first include COFF.h and then windows.h, > COFF::IMAGE_FILE_MACHINE_UNKNOWN > will be preprocessed into >...

It was happening in a few files using COFF.h in LLDB for the windows branch (Windows.h is required for some typedef over Mutex, thread, socket, etc...). As said before, I am currently checking if it could be avoided (probably some refactoring will be needed). However I was wondering if it might not be easier to just avoid this clash at all...

...or symbols with type SymbolRef::ST_Data instead of disassembling them. This causes llvm/test/MC/ARM/Windows/mov32t-range.s to fail, because the symbol "truncation" comes back as SymbolRef::ST_Data, and the code gets dumped as bytes instead of disassembled. I traced the problem back to COFFObjectFile::getSymbolType() in llvm/lib/Object/COFFObjectFile.cpp : if (Characteristics & COFF::IMAGE_SCN_MEM_READ && ~Characteristics & COFF::IMAGE_SCN_MEM_WRITE) // Read only. Result = SymbolRef::ST_Data; I think it should also check for ~Characteristics &a...

...show 67c416dc9a5aeda034d46bdcb3b63fffa462d28e commit 67c416dc9a5aeda034d46bdcb3b63fffa462d28e Author: Vedant Kumar <vsk at apple.com> Date: Thu Nov 14 09:20:58 2019 [DebugInfo] Allow spill slots in call site parameter descriptions [snip] diff --git a/llvm/test/tools/yaml2obj/coff-xrelocs.yaml b/llvm/test/tools/yaml2obj/COFF/xrelocs.yaml similarity index 100% rename from llvm/test/tools/yaml2obj/coff-xrelocs.yaml rename to llvm/test/tools/yaml2obj/COFF/xrelocs.yaml ``` Does anyone know what happened? thanks, vedant > On Nov 15, 2019, at 10:06 AM, Fangrui Song via Phabr...

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(); createImportLi...

Hello everyone, while working on a simple PE-Parser, using the llvm/Support/COFF.h Header, to validate if a given File is a PE-File and to read the Machine Field I was experiencing some troubles. It seemed the Fields were somehow misaligned and I could pinpoint the source of the misalignment to be the "NumberOfSections" field inside the "header"-struct (a.k...

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 Link...

Hello All, I have created a set of patches that get dwarf debugging support working for the COFF object file. I also believe I have fixed what appears to be a bug in how line info sections are referred to from the DW_TAG_compile_unit DIE. I have run some basic tests, analyzed dumps of both the objects files and the final executables, and run a test program against mingw-gdb and everything look...

...windows headers rather than the top level windows.h (e.g #include <winbase.h> but not <windows.h>) [I've never done Windows development, so I'm just stabbing in the dark here] -Nick On Aug 28, 2013, at 7:19 PM, Virgile Bello wrote: > It was happening in a few files using COFF.h in LLDB for the windows branch (Windows.h is required for some typedef over Mutex, thread, socket, etc...). > > As said before, I am currently checking if it could be avoided (probably some refactoring will be needed). However I was wondering if it might not be easier to just avoid this cl...