similar to: [LLVMdev] How to use the LLD linker to link llvm/clang/lld?

Hi, FYI LLD cannot handle ELF sections with non-unique names. An object file with such sections can be generated by the Clang since r234143. I am not sure that Clang works absolutely correct but bfd linker works fine. Right now I do not have a time to investigate this problem. If nobody take, I will try to solve it later. Here is the reproduction script for x86_64 host: $ cat test.cc template

On Fri, Feb 6, 2015 at 5:42 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Fri, Feb 6, 2015 at 5:31 PM, Rui Ueyama <ruiu at google.com> wrote: > > There are two questions. > > > > Firstly, do you think the on-disk format needs to compatible with a C++ > > struct so that we can cast that memory buffer to the struct? That may be > >

There are two questions. Firstly, do you think the on-disk format needs to compatible with a C++ struct so that we can cast that memory buffer to the struct? That may be super-fast but that also comes with many limitations. It's hard to extend, for example. Every time we want to store variable-length objects we need to define string-table-like data structure. And I'm not very sure that

We should make LLD to be able to build with GCC even if GCC is a bit buggy. So you wrote that it's no longer build because of the recent change of makeArrayRef removal? I think it's my change (r196475). Can you confirm that you can build if you revert that change? If it has caused the build with GCC to break, we should roll it back. On Sun, Dec 8, 2013 at 3:45 PM, Mikael Lyngvig

On Sat, Dec 7, 2013 at 10:00 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > On 2013 Dec 7, at 04:23, Mikael Lyngvig <mikael at lyngvig.org> wrote: > >> I am using the -std=c++11 flag to GCC. > > I didn’t even look at your errors, but my understanding is that -std=gnu++11 is more used (and much better tested) than -std=c++11. Any chance that fixes it

Not all input files have to be able to represented in YAML/Native format. There are many unrealistic use cases there. No one wants to write an executable file in Native because there's no operating system that can run that file. So is YAML. So is the combination of .so file and Native/YAML unless we have an operating system whose loader is able to loads a YAML .so file. We might want to write

Yup, I can confirm that. Then the question is if LLD shouldn't compile with GNU, even if GNU is buggy. Personally, I think it is worth a lot to be able to build with GCC, but I don't know how the LLD developers feel about that. -- Mikael 2013/12/7 Simon Atanasyan <simon at atanasyan.com> > On Sat, Dec 7, 2013 at 10:00 PM, Duncan P. N. Exon Smith > <dexonsmith at

I tried this command to undo the change (which should revert to the change just before the one you mentioned): svn update -rr196474 Then I built from scratch. This time it built, so I suppose it is revision 196475 that is the problem. -- Mikael 2013/12/9 Rui Ueyama <ruiu at google.com> > We should make LLD to be able to build with GCC even if GCC is a bit > buggy. So you

I think no one is opposing the idea of reading and writing YAML. The problem here is that why we need to force all developers to write code to serialize intermediate data in the middle of link, which no one except the round-trip passes needs. On Fri, Feb 6, 2015 at 6:41 PM, Shankar Easwaram <shankarke at gmail.com> wrote: > Doing it for every input file is not useful as some of the

Can we remove Native format support? I'd like to get input from anyone who wants to keep the current Native format in LLD. On Thu, Feb 5, 2015 at 2:03 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > The only way currently is to create a new reference, unless we can think > of adding some target specific metadata information in the Atom model. > > This has come up

On Sat, Nov 21, 2015 at 9:28 AM, Rui Ueyama <ruiu at google.com> wrote: > On Fri, Nov 20, 2015 at 10:13 PM, Simon Atanasyan <simon at atanasyan.com> > wrote: >> >> In case of MIPS O32 ABI we have to find a matching R_MIPS_LO16 >> relocation to calculate R_MIPS_HI16 one because R_MIPS_HI16 uses >> combined addend (AHI << 16) + (short)ALO where AHI is

We are modeling target specific functionally using references, Doesn't your idea defeat the purpose of the atom model? Atoms are mostly target neutral and yaml/native format represents just an atom. Having a derived class for atoms will have a impact on the testing method with lld IMO. We could continue to model using references in my opinion and add some meta data information in the atom

On Mon, Apr 20, 2015 at 1:44 AM, Shankar Easwaran <shankarke at gmail.com> wrote: > Attached patch fixes the issue. Thanks for the quick fix. The patch LGTM if you add a test case. Unfortunately yaml2obj does not support duplicated section names but we can use a binary input file. -- Simon Atanasyan

A bit off topic: ARM Group relocations define a logical set of consequent instructions to be relocated to form one single address. For such relocations a 1 to 1 relation is also met, so no need of special processing in applyRelocation. Concerning native format: it also introduced unneeded code complexity to me when I wanted to set calculated relocation addend back into the Reference object in the

Hi, For MIPS it is possible that output executable file contains both GOT entry and R_MIPS_COPY or R_MIPS_REL32 relocation for the same target symbol. If LLD processes the relocation requires GOT entry before the relocation requires COPY dynamic relocation, it generates the correct output. If the order is reversed, LLD emits COPY dynamic relocation only and does not generate a GOT entry (or shows

Hi, I am working on support R_MIPS_HI16 / R_MIPS_LO16 in the new LLD and have a couple of questions. == Q1 In case of MIPS O32 ABI we have to find a matching R_MIPS_LO16 relocation to calculate R_MIPS_HI16 one because R_MIPS_HI16 uses combined addend (AHI << 16) + (short)ALO where AHI is original R_MIPS_HI16 addend and ALO is addend of the matching R_MIPS_LO16 relocation [1]. There are two

Hi, The round trip passes just tries to load a *complete* object file in YAML/Native format back. The internal state should be the complete object file in native/yaml format. If some state is not recorded and that is really needed in the writer, we should add that to the Atom model. Shankar Easwaran On 2/9/2015 1:29 PM, Rui Ueyama wrote: > I want to bring this again because I think

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

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

On Sat, Nov 21, 2015 at 10:08 AM, Rui Ueyama <ruiu at google.com> wrote: > On Fri, Nov 20, 2015 at 11:02 PM, Simon Atanasyan <simon at atanasyan.com> > wrote: >> >> On Sat, Nov 21, 2015 at 9:28 AM, Rui Ueyama <ruiu at google.com> wrote: >> > On Fri, Nov 20, 2015 at 10:13 PM, Simon Atanasyan <simon at atanasyan.com> >> > wrote: >>