similar to: Embedding LLD version to executables

----- Original Message ----- > From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Rui Ueyama" <ruiu at google.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, October 18, 2016 10:22:00 PM > Subject: Re: [llvm-dev] Embedding LLD version to executables > > > > On Oct 18, 2016, at 6:44

On Tue, Oct 18, 2016 at 8:22 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Oct 18, 2016, at 6:44 PM, Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > I'd like to make LLD embed version information so that we can determine > if an executable was created by LLD and if that's the case which version of > LLD. >

----- Original Message ----- > From: "Mehdi Amini" <mehdi.amini at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Rui Ueyama" > <ruiu at google.com> > Sent: Tuesday, October 18, 2016 10:38:57 PM > Subject: Re: [llvm-dev] Embedding LLD version to executables >

Hi, > Scenario 1: you added -fuse-ld=lld to your command line, but you are suspecting that the option is ignored. Currently, it's actually surprisingly hard to tell if an output was created by LLD. Can't you use -v to see what linker the compiler driver invoked? On Wed, Oct 19, 2016 at 4:41 AM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Tue, Oct 18,

> Le 3 oct. 2017 à 00:09, Rui Ueyama <ruiu at google.com> a écrit : > > I read through the binutils mailing list thread, but I couldn't find the exact reason why making --hash-style=gnu default except MIPS wasn't a good idea.Do you mind if I ask you to explain it again for me? > > Since lld is a new linker, we could make a bit more radical change than GNU ld can do,

Hello, We’d like to keep track of which clang version was used to build our LLVM binaries. We use cmake and ninja with clang to build. What do you people think would be the cleanest way to know which version of clang is used, on a user’s machine, to build those binaries. I’m hoping to script this. I was thinking that getting cmake/ninja to spit out this information, if possible, would probably be

>I'd like to make LLD embed version information so that we can determine if an executable was created by LLD and if that's the case which version of LLD. >ld.bfd doesn't seem to embed any information, so we cannot tell whether an executable was linked by ld.bfd or not easily. >ld.gold embeds a string "GNU gold <version>" as ".note.gnu.gold-version"

Hi, Sorry for delay with reply. It looks like now thunks can be implemented as a synthetic sections. In that case we give flexible solution and will be able to put thunks before/after related sections, using different alignment etc. As far as I know BFD linker uses the same approach at least for MIPS thunks. I will try to implement this idea. On Thu, Sep 8, 2016 at 1:44 AM, Rui Ueyama <ruiu

Michael Johnson <mpj at rowley.co.uk> writes: > Hi Rafael, >> Michael Johnson via llvm-dev <llvm-dev at lists.llvm.org> writes: >> >>> Hi Rui, >>> >>> Are there any plans to support the -defsym command line option? >> It doesn't look that hard, it was just never requested. What project is >> using it? > Not sure I understand

Initial issue is related to R_MIPS_GPREL16/32 relocations. When we calculate such relocations we need to know _gp symbol's value. This value might come from different sources. Usually we setup it using constant offset from the .got section. Also it might be defined by a linker script. And in rare but possible case it comes from .reginfo / .MIPS.options sections. Got example, GNU bfd linker

On 28 October 2016 at 18:12, Ed Maste <emaste at freebsd.org> wrote: > It should be possible to search the path for ld.lld first, then ld, > but to me it seems like it will just be more confusing. Hum, for me it would be less confusing. :) GCC uses bfd by default, LLVM uses LLD. If you want to change, use -fuse-ld. What would be confusing in this scenario? > Clang's current

On Mon, Jan 16, 2017 at 12:31 PM, Sean Silva <chisophugis at gmail.com> wrote: > Do we have any open projects on LLD? > > I know we usually try to avoid any big "projects" and mainly add/fix > things in response to user needs, but just wondering if somebody has any > ideas. > > Some really generic/simple stuff I can think of: > 1. trying out LLD on a large

Sure. One thing I want to remind you is that there is a place in Writer.cpp where we assume all synthetic sections were appended to end of Sections list. Look for `llvm::reverse`. If you add synthetic section thunks right before/after non-synthetic sections, you also want to change that. On Tue, Nov 29, 2016 at 1:18 PM, Simon Atanasyan <simon at atanasyan.com> wrote: > Hi, > >

Le 2 oct. 2017 à 18:37, Rui Ueyama <ruiu at google.com<mailto:ruiu at google.com>> a écrit : Changing default to "both" is probably fine, but what does that change actually mean in practice? I believe clang already passes --hash-style=both to the linker by default. Not exactly. The current Linux driver (I haven't checked other ELF-based systems) reads this

Hi, MIPS LA25 thunk is used to call PIC function from non-PIC code. Usually it contains three instructions: lui $25, %hi(func) addiu $25, $25, %lo(func) j func We can write such thunk in an arbitrary place of the generated file. But if a PIC function requires the thunk is the first routine in a section, we can optimize the code and escape jump instruction. To do so we just write the

I spent a week to optimize LLD performance and just wanted to share things what I found. Also if there's anyone who have a good idea on how to make it faster, I'd like to hear. My focus is mainly on Windows, but my optimizations are generally platform neutral. I aim both single-thread and multi-thread performance. r231434 <http://reviews.llvm.org/rL231454> is a change that has the

Hello all, The lld linker appears to generate extra ELF program headers and thus causes file sizes to be significantly larger than what would get with ld.gold or ld.bfd. # readelf -l test.bfd Elf file type is EXEC (Executable file) Entry point 0x4000b0 There are 2 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr

Thanks for your response! On 30/01/2019 20:18, Rui Ueyama wrote: > Hi Josef, > > Let me clarify my understanding. Do you want to keep original bitcode > files in the output executable when doing LTO, so that the resulting > executable contains both compiled bitcode (which is in native machine > instructions) and original bitcode files? Exactly! Kind of analogous to what

On Thu, Jan 31, 2019 at 11:05 AM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > That feature is probably too specific to your project. Most projects that > use LTO are using LTO just because it generates better code. Your project > is special as your program itself can also interpret LLVM bitcode, but > that's not the case for most other programs. > I

I've noticed that lld keeps the data section more isolated than the gold or bfd linkers. For example, readelf -l applied to the "same" executable linked with those three linkers reveals the following under "Section to Segment mapping": lld: 05 .data .got.plt .bss gold: 03 .eh_frame .init_array .fini_array .preinit_array .dynamic .got .got.plt .data .bss bfd: 05