search for: elf2

Hi, I need an advice how to support both big and little endian MIPS targets in the new LLD ELF design and escape code duplication. MIPS 32-bit big and little endian targets are very similar and differ in read/write functions. There are some options how to support both but I cannot make the best choice. 1. Make MipsTargetInfo a class template. Use the template's argument to select read/write

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

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

...hreads 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 different implementations of the same concept, AFAIU), but one is usable as a library (and even does not require round-tripping generated code through an object file! I was really happy to use that) and the other one isn't. Not sure what the future plans are for...

...ent changes to offset them. The commit that increased link time most (+15%) is r251212: Add support for merging string from SHF_STRINGS sections. This does not come as a surprise since string merging is a computationally heavy operation. The commit that decreased link time most (-29%) is r250315: ELF2: Merge .{text,rodata,data,bss}.* sections. This is because the commit significantly decreased number of sections in the output. The following commits are also noteworthy. - r257017: ELF: Improve performance of string table construction (-14.0%) - r251332: Optimize StringTableBuilder (-7.8%) Id...

...ble threads, much less than the 48 each test believes it can use. This is somewhat non-deterministic, but I just reran things both ways, and here's what I see: During my last run, these tests fail when running under lit with many parallel tests, but do not fail when run otherwise: lld :: elf2/basic.s lld :: elf/AArch64/general-dyn-tls-0.test lld :: elf/AArch64/initial-exec-tls-0.test lld :: elf/AArch64/rel-prel32-overflow.test lld :: elf/AArch64/rel-prel64.test lld :: elf/AMDGPU/hsa.test lld :: elf/ARM/arm-symbols.test lld :: elf/ARM/dynamic-symbols.test...

...uot; on axis(4). It looks like the program does not know where or how long axis(4) should be. I have been stuck with this problem for the past couple of days, desperately need help. Thanks Deepa Rajamani -------------- next part -------------- A non-text attachment was scrubbed... Name: EHF,ERG,ELF2,ELF3.pdf Type: application/pdf Size: 54050 bytes Desc: EHF,ERG,ELF2,ELF3.pdf URL: <https://stat.ethz.ch/pipermail/r-help/attachments/20090316/6b56729d/attachment-0003.pdf>

...ach test believes it can use. > > This is somewhat non-deterministic, but I just reran things both > ways, and here's what I see: > > During my last run, these tests fail when running under lit with many > parallel tests, but do not fail when run otherwise: > > lld :: elf2/basic.s > lld :: elf/AArch64/general-dyn-tls-0.test > lld :: elf/AArch64/initial-exec-tls-0.test > lld :: elf/AArch64/rel-prel32-overflow.test > lld :: elf/AArch64/rel-prel64.test > lld :: elf/AMDGPU/hsa.test > lld :: elf/ARM/arm-symbols.test > lld :: elf/ARM/dynamic-symbols.te...

...;> >> This is somewhat non-deterministic, but I just reran things both ways, >> and here's what I see: >> >> During my last run, these tests fail when running under lit with many >> parallel tests, but do not fail when run otherwise: >> >> lld :: elf2/basic.s >> lld :: elf/AArch64/general-dyn-tls-0.test >> lld :: elf/AArch64/initial-exec-tls-0.test >> lld :: elf/AArch64/rel-prel32-overflow.test >> lld :: elf/AArch64/rel-prel64.test >> lld :: elf/AMDGPU/hsa.test >> lld :: elf/ARM/arm-sym...

Hi Rui, et al., I was experimenting yesterday with building lld on my POWER7 PPC64/Linux machine, and ran into an unfortunate problem. When running the regressions tests under lit, almost all of the tests fail like this: terminate called after throwing an instance of 'std::system_error' what(): Resource temporarily unavailable ... 5 libc.so.6 0x00000080b7847238 abort +

...lot of contributors and hit some important milestones. > So, I encourage LLD to keep its interfaces highly specialized for the users > it actually has -- and indeed today that may be exactly one user, the > command line linker. We have a highly specialized api consisting of one function: elf2::link(ArrayRef<const char *> Args). That fits 100% of the uses we have. If there is ever another use we can evaluate the cost of supporting it, but first we need to actually write the linker. Note that this is history replaying itself in a bigger scale. We used to have a fancy library to han...

...t; 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 >>>> importance for my use case): >>>> >>>> 1. Detecting errors in the first place. New linker seems to call >>>> exit(1) for any error. >>>> >>>> 2. Reportin...

...n Thu, Jan 7, 2016 at 7:03 AM, Arseny Kapoulkine via llvm-dev < >>> llvm-dev at lists.llvm.org <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>> 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 >>>> importance for my use case): >>>> >>>> 1. Detecting errors in the first place. New linker seems to call >>>> exit(1) for any error. >>>> >>>> 2. Reportin...

...t; > So, I encourage LLD to keep its interfaces highly specialized for the >> users >> > it actually has -- and indeed today that may be exactly one user, the >> > command line linker. >> >> We have a highly specialized api consisting of one function: >> elf2::link(ArrayRef<const char *> Args). That fits 100% of the uses we >> have. If there is ever another use we can evaluate the cost of >> supporting it, but first we need to actually write the linker. >> > > Note that I'm perfectly happy with this *interface* today, p...

...;>> >>>>> 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 importance for my use case): >>>>>> >>>>>> 1. Detecting errors in the first place. New linker seems to call >>>>>> exit(1) for any error. >>>&...

...t 7:03 AM, Arseny Kapoulkine via llvm-dev < > *>>>* llvm-dev at lists.llvm.org <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>> 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 > *>>>>* importance for my use case): > *>>>>>>>>* 1. Detecting errors in the first place. New linker seems to call > *>>>>* exit(1) for any error. > *>>>>&gt...

...t 7:03 AM, Arseny Kapoulkine via llvm-dev < > >>> llvm-dev at lists.llvm.org <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>> 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 > >>>> importance for my use case): > >>>> > >>>> 1. Detecting errors in the first place. New linker seems to call > >>>> exit(1) for any error. > >>>> &gt...

...es highly specialized for the >>>> users >>>> > it actually has -- and indeed today that may be exactly one user, the >>>> > command line linker. >>>> >>>> We have a highly specialized api consisting of one function: >>>> elf2::link(ArrayRef<const char *> Args). That fits 100% of the uses we >>>> have. If there is ever another use we can evaluate the cost of >>>> supporting it, but first we need to actually write the linker. >>>> >>> >>> Note that I'm perfec...

...n 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 importance for my use case): >>>>>>>> >>>>>>>> 1. Detecting errors in the first place. New linker seems to call >>>>>>>> exit...

Sorry for being late on this thread. I just wanted to say I am strongly on Rui's side on this one. There current design is for lld *not* not be a library and I think that is important. That has saved us a tremendous amount of work for doing library like code and a lot of design for library interfaces. The comparison of old and new ELF code is night and day as far as productivity and