similar to: state of the lld linker for aarch64

On 19 April 2016 at 06:59, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Dima, > > Adhemerval is working on AArch64 support, and it should be mostly > there, though some missing TLS support. He should know more. Here's some info on TLS. Review D18960 has the initial implementation for TLSDESC support: http://reviews.llvm.org/D18960 I've been

On 2 June 2016 at 20:49, Rafael Espindola via llvm-commits <llvm-commits at lists.llvm.org> wrote: > Author: rafael > Date: Thu Jun 2 14:49:53 2016 > New Revision: 271569 > > URL: http://llvm.org/viewvc/llvm-project?rev=271569&view=rev > Log: > Start adding tlsdesc support for aarch64. > > This is mostly extracted from http://reviews.llvm.org/D18960. Rafael,

On 3 June 2016 at 18:47, Rui Ueyama <ruiu at google.com> wrote: > Renato, it is not appropriate to call it my and Rafael's pet project. Hi Rui, I apologise, that was wrong in all levels. I know how much other people have contributed, but these people are on the inside already, so their contributions are more easily accepted. We have been trying to contribute for more than a year

On 3 June 2016 at 01:53, Rui Ueyama <ruiu at google.com> wrote: > Not so fast to conclude that the community is not trustworthy, it doesn't > consist of a single person or a single action. This is not an isolated incident. This seems to be the general behaviour around LLD, which is less so in the rest of the LLVM projects. The obliteration of the old ELF back-end was discussed

On 3 June 2016 at 17:10, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Do keep in mind you are comparing a 11 year old project and a 11 month > old one. There is a lot more churn on the 11 month old one. LLD is at least 5 years old. Every time you re-write it doesn't reset history. > Again, I am truly sorry we were unable to come up with a perfect > design the

On 2 June 2016 at 23:22, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Because the patch includes way too much and doesn't explain what it is doing. So let me get this straight: someone publishes a patch, you don't like it, you do some private investigations and commit whatever you want without even notifying the original authors? I don't know how you work at

tl;dr: TLSDESC have solved most problems in formerly inefficient TLS access models, so I think we can drop TLS relaxation support from lld. lld's code to handle relocations is a mess; the code consists of a lot of cascading "if"s and needs a lot of prior knowledge to understand what it is doing. Honestly it is head-scratching and needs serious refactoring. I'm trying to simplify

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

On Tue, Nov 7, 2017 at 6:59 PM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > tl;dr: TLSDESC have solved most problems in formerly inefficient TLS > access > > models, so I think we can drop TLS relaxation support from lld. > > > > lld's code to handle

On Tue, Nov 7, 2017 at 8:16 PM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Rui Ueyama <ruiu at google.com> writes: > > >> So I am strongly against removing either non TLSDESC support of support > >> for the relaxations. > >> > > > > It's still pretty arguable. By default, compilers use General Dynamic > model

Hi, Yes, ldd is generating wrong tbss size. It is just considering one tbss section and not calculating all sections from all objects. The following example on x86_64 shows the issue: --- t0.c --- #include <stdio.h> extern __thread int t0; extern __thread int t1; extern __thread int t2; extern __thread int t3; __thread int t4; __thread int t5; __thread int t6; __thread int t7; int

On Fri, 2012-07-20 at 08:36 +0200, Duncan Sands wrote: > Hi Adhemerval Zanella, the old JIT infrastructure is going away, to be replaced > by "MC-JIT" (try passing -use-mcjit to lli). It sounds like you are working on > the old JIT, so I suggest you work instead on getting MC-JIT working on powerpc. Hi Duncan, Thanks for the pointers. We hadn't stumbled across the

On 07/20/2012 10:35 AM, Will Schmidt wrote: > On Fri, 2012-07-20 at 08:36 +0200, Duncan Sands wrote: >> Hi Adhemerval Zanella, the old JIT infrastructure is going away, to be replaced >> by "MC-JIT" (try passing -use-mcjit to lli). It sounds like you are working on >> the old JIT, so I suggest you work instead on getting MC-JIT working on powerpc. > Hi Duncan,

On Wed, Nov 8, 2017 at 9:33 AM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Rui Ueyama <ruiu at google.com> writes: > > >> If you are creating an executable and if your executable is not > >> > position-independent, you're using Initial Exec model by default > which is > >> > as fast as variables accessed through

Looks like it is also not working on x86_64, using clang/lld I am seeing a segmentation fault: Dump of assembler code for function _Z4funcj: 0x0000000000400590 <+0>: push %rbp 0x0000000000400591 <+1>: push %rbx 0x0000000000400592 <+2>: push %rax 0x0000000000400593 <+3>: mov %edi,%ebp 0x0000000000400595 <+5>: pop %rdx 0x0000000000400596

On 2 November 2015 at 18:40, Adhemerval Zanella <adhemerval.zanella at linaro.org> wrote: > Is it 39 or 42-bit VMA? I noted a 42-bit issue in segment definition > that I have fixed on my TSAN unification mapping patch [1]: No, that's 39-bit. cheers, --renato

On 07/31/2012 11:26 AM, Adhemerval Zanella wrote: > On 07/20/2012 10:35 AM, Will Schmidt wrote: >> On Fri, 2012-07-20 at 08:36 +0200, Duncan Sands wrote: >>> Hi Adhemerval Zanella, the old JIT infrastructure is going away, to be replaced >>> by "MC-JIT" (try passing -use-mcjit to lli). It sounds like you are working on >>> the old JIT, so I suggest

I'd like to convert the following call A at GDPLT //R_HEX_GD_PLT_B22_PCREL to call __tls_get_addr //R_HEX_B22_PCREL "A" is a TLS variable and preceding code has prepared for the call. When the R_HEX_GD_PLT_B22_PCREL is found it will initially point to the TLS variable so at that point I'd like to define a __tls_get_addr symbol and update the relocation's type and symbol

Hi, I am tracking some TLS issues with lld and found that it is generating wrong tbss size for case where multiple modules have non initialized threads variables. For instance: -- t0.c -- __thread int x0; __thread int x1; __thread int x2; extern __thread int e0; extern __thread int e1; extern __thread int e2; extern __thread int e3; int foo0 () { return x0; } int main () { return x0; }

Hi, Checking the llvm test-suite SingleSource/Regression/C++/EH/class_hierarchy testcase on aarch64 I noted something strange: Dump of assembler code for function _Z4funcj: 0x0000000000400650 <+0>: stp x22, x21, [sp,#-48]! 0x0000000000400654 <+4>: stp x20, x19, [sp,#16] 0x0000000000400658 <+8>: stp x29, x30, [sp,#32] 0x000000000040065c