search for: coffe

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 *

+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(); > +

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

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

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.h and then COFF.h, COFF.h won't work because it's enum will

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

> On 9 Feb 2018, at 10:20, Hans Wennborg <hans at chromium.org> wrote: > > 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

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

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.

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 for ELF and COFF), so that

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

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 by avoiding it in LLVM. Alternatively I could #undef

I'm working on adding data detection to llvm-objdump, so it prints out raw data for 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

I just got a Diffusion notification about a change of mine being reverted by Fangrui, but I'm not sure that's actually what happened and am confused and concerned. My commit was "[DebugInfo] Allow spill slots in call site parameter descriptions", and it appears in the history under two hashes: 1ee84e and 67c416. The first commit contains the actual change. The second touches

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); -

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

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

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 looks

In the Windows SDK headers, is the IMAGE_* defines in a separate file (e.g. winint.h)? Does the file have a guard against multiple inclusion? If so (and the guard was named _WINNT_H_), perhaps you can do something like: #define _WINNT_H_ #include <windows.h> So you would get everything except those file format defines. Of course, this would fail if other parts of the windows header rely