similar to: [lld] r271569 - Start adding tlsdesc support for aarch64.

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

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

Hi, Some time ago there were some information about aarch64 support for the lld linker project: http://lld.llvm.org/open_projects.html#elf-aarch64 Right now there is no such information. Also there is some presentation described that the simple application can be linked using lld: http://llvm.org/devmtg/2016-03/Presentations/EuroLLVM%202016-%20New%20LLD%20linker%20for%20ELF.pdf What is the

Hi Adhemerval, Some UBSan tests are timing out randomly. http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full ex: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/902 http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/894 http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/906

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

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

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

Wait, this change is not submitted yet, right? Or you mean mailing of this change in bad shape? I consider this change as work-in-progress where author is looking for feedback on his ongoing progress. I guess the change description should have been spelled this very explicitly. This change definitely needs more work to be submitted, splitting into smaller patches with a plan for submission order,

On Wed, Aug 19, 2015 at 1:15 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 19 August 2015 at 11:29, Dmitry Vyukov <dvyukov at google.com> wrote: >> Wait, this change is not submitted yet, right? Or you mean mailing of >> this change in bad shape? > > Right. > > Jason has submitted high quality patches before, so this is in no way > a reprimand

IMO having to disable 2/3 of the tests means the patch isn't ready yet. On Fri, Aug 28, 2015 at 9:31 AM, Jason Kim <jasonk at codeaurora.org> wrote: > > > > -----Original Message----- > > From: Renato Golin [mailto:renato.golin at linaro.org] > > > TESTS! > > > Currently, about 2/3 tests for tsan fail/flake on android+aarch64. > > >

Adding Jiangning Liu to the thread. Jiangning reported a similar issue on the llvm-commits list on Debian aarch64. In general it sounds like std::call_once may not really be bug free. Jiangning, can you please provide your gcc/libstdc++ version? Thanks, -Chris > On Nov 4, 2014, at 9:38 AM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote: > > On Tue, 2014-11-04 at 12:17

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

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

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

It seems the crash of llvm/clang build on aarch64 Debian has been fixed by r220941. Thanks, -Jiangning 2014-11-05 8:45 GMT+08:00 Jiangning Liu <liujiangning1 at gmail.com>: > The versions I'm using right now are > > * gcc: (Debian/Linaro 4.9.1-14) 4.9.1 > * libstdc++: libstdc++.so.6.0.20 > > Thanks, > -Jiangning > > 2014-11-05 4:46 GMT+08:00 Chris Bieneman

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,

Hi folks, After long talks with lots of people, I think we have a winning strategy to deal with the variable nature of VMA address in AArch64. It seems that the best way forward is to try the dynamic calculation at runtime, evaluate the performance, and then, only if the hit is too great, think about compile-time alternatives. I'd like to know if everyone is in agreement, so we could get