similar to: [LLVMdev] Re: ELF / COFF Interface

On Wed, 15 Jun 2005, Reid Spencer wrote: > So, here's the plan: > > 1. No reading interface. To have a system agnostic interface for reading > a dynamic library, use System/DynamicLibrary. No plans for reading a > native object file for any kind of examination purpose (at least, not > for a long while). Sounds good. > 2. We will support .so/.dll and .o/.obj file output.

We've had various discussions about ELF/COFF support in LLVM. Here's a summary and action plan. 1. Do we need a "reading" interface? * Reid: No * Alexander: Yes * Chris: No * Jeff: We already have this in lib/System (DynamicLibrary.h) 2. Do we support just .so/.exe or all object formats? * Reid: Just .so/.dll .exe and .o * Alexander: Just

On 12 September 2016 at 16:23, Rui Ueyama <ruiu at google.com> wrote: > What's the motivation to not build COFF and Mach-O parts? If you don't need > it, you could just leave it. Are you trying to reduce the executable size? It was just easier to remove coff::link() and mach_o::link() from lld.cpp than to add them to our own build infrastructure

TL;DR: I'm trying to evaluate if LLD can be used with GHC (Glasgow Haskell Compiler) on Windows. Haskell binary code is usually deployed in "packages". A package typically provides static library(ies) and optionally – shared library(ies) and/or prelinked ('ld -r') object file. The latter is the best way to satisfy GHC runtime linker, since it requires no separate

We're in the process of importing lld into FreeBSD (along with our Clang 3.9 update project). For now I've removed all but the ELF linker[1]. We have no need for COFF and Mach-O, and we have a bespoke build system for all of our contrib code. I didn't bother adding build support for the source files for non-ELF linkers. Is this something that'd be reasonable / desirable to have

On Thu, Jan 7, 2016 at 7:18 AM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Jan 7, 2016 at 7:03 AM, Arseny Kapoulkine via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> In the process of migrating from old lld ELF linker to new (previously >> ELF2) I noticed the interface lost several important features (ordered by >>

Author: ahl Repository: /hg/zfs-crypto/gate Revision: 0f27629eb96eb9ce7ab1322830d1f3839b9c7da1 Log message: PSARC 2005/689 ELF Extended Program Headers 6317969 elfheader limited to 65535 segments 6317980 coredump elfheader doesn''t reflect the correct number of dumped segments 6343698 p-tools affected by 6317980 : coredump elfheader incorrectly states number of dumped segments 6350070 stub

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: >

Chris Lattner wrote: > On Thu, 9 Jun 2005, Alexander Friedman wrote: > >> On Jun 9, Chris Lattner wrote: >> >>>> I'm happy with .so. What purpose would .o files serve? >>> >>> >>> Speeds up compile time by not having to write out a .s file then run >>> the >>> system assembler on it. Likewise, emitting a .so file

>> We still have a dependency on the system linker, but in time that >> could be addressed. Note that VC++ distributes a native linker, but I >> don't think it distributes a native assembler (I could be wrong though). > > You are correct. Microsoft does not distribute an assembler with Visual > Studio anymore (hasn't for some time). Its called ML.EXE now

Oh, so *that's* what happened to MASM. OK, change of plans. Forget NASMW, target ML. Aaron Gray wrote: >>> We still have a dependency on the system linker, but in time that >>> could be addressed. Note that VC++ distributes a native linker, but >>> I don't think it distributes a native assembler (I could be wrong >>> though). >> >>

The context issue may be solved by making all functions and context data members of a class. Sort of having the convenience of global variables accessible from all linker functions but without the regular global variable problems of initializing and re-entry. so the class is suitable aspart of a library. Most clang and LLVM classes works this way, not passing contexts around. 2016-01-22 6:25

On Sat, Jan 23, 2016 at 6:42 AM, Eric Christopher via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Rafael, > > This is an unreasonable and unacceptable escalation of this thread. You have > been dismissive, derailing, and taking out of context everything Chandler, > and other long term active contributors have been asking and talking about. > Your tone has been

----- Original Message ----- > From: "Rafael Espíndola via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Yaron Keren" <yaron.keren at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Arseny Kapoulkine" <arseny.kapoulkine at gmail.com> > Sent: Tuesday, January 26, 2016 9:39:34 AM > Subject: Re: [llvm-dev] lld:

In the process of migrating from old lld ELF linker to new (previously ELF2) I noticed the interface lost several important features (ordered by importance for my use case): 1. Detecting errors in the first place. New linker seems to call exit(1) for any error. 2. Reporting messages to non-stderr outputs. Previously all link functions had a raw_ostream argument so it was possible to delay the

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 *

This is really unfortunate. I've read the discussion threads for the atom/chunk controversy and I feel like I understand the reasons for rewriting the linker, but this does not seem to have anything to do with whether the linker is usable as a library or not. As it stands, not only does lld have two completely different linkers (I'm treating COFF/ELF2 as one since they are really two

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

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

Michael, I have not made any changes since I last posted a patch. If you would like to make the final updates, thats fine by me. I don't mind making the changes either, I can have them done this evening as well. Chris, As far as naming goes, PE/COFF used in Microsoft's document because they are describing both their version of COFF, and their Portable Execution format which is a