similar to: lld: add build-time control for including ELF / COFF / Mach-O linkers?

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

Hi, This was the commit of SA-12:04.sysret to RELENG_7_4, which makes sense to me: http://svnweb.freebsd.org/base/releng/7.4/sys/amd64/amd64/trap.c?r1=216618&r2=236953 But when it was applied to RELENG_8_1, it looks wrong, as if it was applied in the wrong place. The indentation is broken, and the code inserted looks like it wouldn't be effective:

Is the new EH scheme completely compatible with the existing linker in Xcode 4.1? I am finding that today's changes break the ability to link xplor-nih with dragonegg under FSF gcc 4.6.2... de-g++46 -c thread.cc -O3 -ffast-math -funroll-loops -g -DX_MMAP_FLAGS=0 -DFORTRAN_INIT -fno-common -DDARWIN -D_REENTRANT -DNDEBUG -I/Users/howarth/xplor-nih-2.27/vmd/

On 10/02/15 13:17, Dimitry Andric wrote: > On 09 Feb 2015, at 18:52, Sedat Dilek <sedat.dilek at gmail.com> wrote: >> >> On Mon, Feb 9, 2015 at 6:44 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote: >>> On 07/02/15 22:42, Sedat Dilek wrote: > ... >>>> In file included from ../../src/mapi/entry.c:49: >>>> ./entry_x86-64_tls.h:66:1:

Am Montag, 16. Februar 2015, 12:42:19 schrieb Sedat Dilek: > On Mon, Feb 16, 2015 at 10:39 AM, Marc Dietrich <marvin24 at gmx.de> wrote: > > Am Samstag, 14. Februar 2015, 18:20:12 schrieb Dimitry Andric: > >> On 11 Feb 2015, at 11:16, Sedat Dilek <sedat.dilek at gmail.com> wrote: > >> > On Wed, Feb 11, 2015 at 12:09 AM, Emil Velikov > >> >

Am Samstag, 14. Februar 2015, 18:20:12 schrieb Dimitry Andric: > On 11 Feb 2015, at 11:16, Sedat Dilek <sedat.dilek at gmail.com> wrote: > > On Wed, Feb 11, 2015 at 12:09 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote: > >> On 10/02/15 13:17, Dimitry Andric wrote: > >>> On 09 Feb 2015, at 18:52, Sedat Dilek <sedat.dilek at gmail.com> wrote:

On 11 Feb 2015, at 11:16, Sedat Dilek <sedat.dilek at gmail.com> wrote: > > On Wed, Feb 11, 2015 at 12:09 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote: >> On 10/02/15 13:17, Dimitry Andric wrote: >>> On 09 Feb 2015, at 18:52, Sedat Dilek <sedat.dilek at gmail.com> wrote: >>>> >>>> On Mon, Feb 9, 2015 at 6:44 PM, Emil Velikov

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

Hi all, llvm-readelf is an alias for llvm-readobj which aims for GNU compatibility and is likely the tool that most people migrating to the LLVM binutils will adopt instead of llvm-readobj. Because it is just an alias, it has inherited the functionality provided by llvm-readobj, including for non-ELF targets, with Mach-O and COFF-specific switches available in its interface. People migrating from

W dniu 2019-04-04 o 09:18, Tim Northover pisze: > On Wed, 3 Apr 2019 at 19:05, Audiovisart via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Does LLVM 8 work in macOS 10.9.5? > It should do. The released binaries appear to have been compiled so > they can run on that version, and Apple Clang 6.0 (from the newest > Xcode that runs on 10.9) meets the build

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

Alexander Friedman wrote: >>Yeah, you don't want anything like BFD. >> >> >> >>>Here's some things I've discovered so far and associated questions: >>> >>>1) We're really only interested in a writing interface to create the >>>object files. If we get that right we can use dlsym and friends to do >>>the

Does LLVM 8 work in macOS 10.9.5? -- Mark

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

> In the case of the ELF writer, we want a similar structure. Anything that > can be simple exposed as data should be (e.g. whether the target is 32- or > 64-bit), anything more complex should be exposed as virtual methods that > are overloaded. The ELF spec makes it very clear what parts of the file > format are common across targets and what the variations are caused by.

My personal preference is that llvm-readelf only show the elf related options with -help and show all with -help-hidden. There is support for this in CommandLine.h, but I don't know how tricky it gets when we don't want them to be hidden for llvm-readobj. I haven't looked into this fully. For some reference, I have compiled how the other alias tools are handled. Many of these are

1. A program can use SSE instructions only if both CPU and OS support SSE. Currently libFLAC tests both CPU and OS for this support, but is it really necessary? Maybe CPU check is enough? Operating systems that don't support SSE (Win95, WinNT 4.0, Linux kernel 2.2 (iirc), ...) are really outdated now. Removing OS check will greatly simplify src/libFLAC/cpu.c. 2. "configure" build

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.