similar to: [LLVMdev] [lld] TBSS wrong size

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

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

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 Tue, May 08, 2012 at 12:57:15AM +0200, Ivan Llopard wrote: > Le 07/05/2012 17:15, Joerg Sonnenberger a écrit : > >On Mon, May 07, 2012 at 05:15:59PM +0200, Ivan Llopard wrote: > >>Thanks for your quick response Joerg. > >> > >>We have a very small test case where there is global array and its > >>address space attribute specified like in the

Hello, I am currently working with PPC64 JIT support for LLVM. So far I could make function calls work by adding function descriptors in 'lib/Target/PowerPC/PPCJITInfo.h' and adding a virtual method at 'LLVM::TargetJITInfo' that is called within 'JITEmitter::finishFunction' just after 'sys::Memory::InvalidateInstructionCache' to update the Global Mapping with

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. Ciao, Duncan. > I am currently working with PPC64 JIT support for LLVM. So far I could make function calls > work by adding function

Hi Galina, The failing build was http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/10220 and the commit that caused it was 'r251331 [compiler-rt] Fix ptrace interceptor for aarch64'. ________________________________ From: Galina Kistanova [gkistanova at gmail.com] Sent: 02 November 2015 16:03 To: Daniel Sanders Cc: Renato Golin; Bill Seurer; LLVM Dev Subject: Re: [llvm-dev]

Hi all, Working on lld aarch64 support I came across an issue where I am not sure which would be best design approach to solve. The aarch64 R_AARCH64_ABS64 relocation for PIC/PIE build requires a dynamic relocation (R_AARCH64_RELATIVE) with the value set as the addend of the relocation. For instance, when linking the crtbeginS.o which contains: Relocation section '.rela.init_array' at

Actually I am trying to run SPEC2006 through the Makefiles provided with LLVM Test Suite, so I think it should work properly... On 18 February 2013 15:49, Adhemerval Zanella <azanella at linux.vnet.ibm.com>wrote: > I can't really tell what is happening based on this output, but 'make' is > not the right way > to build SPECcpu2006 components. You need to do either by

From: Dejan Latinovic <Dejan.Latinovic at imgtec.com> --- usr/include/arch/mips64/klibc/archconfig.h | 3 + usr/include/arch/mips64/klibc/archsetjmp.h | 39 ++++++ usr/include/arch/mips64/machine/asm.h | 76 ++++++++++ usr/include/fcntl.h | 2 +- usr/include/sys/md.h | 1 + usr/include/sys/resource.h | 4 +-

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

Hi I am writing a freestanding statically linked x86_64 kernel. And now I want to load and use thread-local storage. As I have a freestanding binary I can't use libc/Linux kernel thread-local mechanism and need to implement initialization code by myself. I am trying to find a clear explanation of what is the memory layout for x86 TLS but can't find anything useful. Maybe LLVM developers

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

Le 07/05/2012 17:15, Joerg Sonnenberger a écrit : > On Mon, May 07, 2012 at 05:15:59PM +0200, Ivan Llopard wrote: >> Thanks for your quick response Joerg. >> >> We have a very small test case where there is global array and its >> address space attribute specified like in the following code >> >> const int __attribute__((address_space(256))) fangle[13] =

I can't really tell what is happening based on this output, but 'make' is not the right way to build SPECcpu2006 components. You need to do either by using the supplied 'runspec' command with '-build' action directive or to issue the 'specmake' (which is a make adjusted by spec.org) on the build component folder. I can build 433.milc on PPC64 with clang without