search for: adhemerval

...(8 ints). On 02-06-2015 21:14, Shankar Easwaram wrote: > Are you saying it generates wrong section size? Tbss is very special and I checked the behavior on X86_64 to model it. It does not account for virtual address increase as libc allocates it. > > >> On Jun 2, 2015, at 17:20, Adhemerval Zanella <adhemerval.zanella at linaro.org> wrote: >> >> 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: >> &g...

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, > Thanks for the poin...

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

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

...xt segment. On 06-05-2015 18:18, Shankar Easwaran wrote: > Does this test pass on X86_64 ? Groups are read in the Reader and is documented below :- > > See http://lld.llvm.org/design.html#linking-steps on Section Groups to get more information. > > On Wed, May 6, 2015 at 9:43 AM, Adhemerval Zanella <adhemerval.zanella at linaro.org <mailto:adhemerval.zanella at linaro.org>> wrote: > > Hi, > > Checking the llvm test-suite SingleSource/Regression/C++/EH/class_hierarchy > testcase on aarch64 I noted something strange: > > Dump of assemb...

...fael > 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, Why commit part of Adhemerval's patch without reviewing his request? This is a really serious breach of community trust. Not only we're waiting for reviews on the TLS set of patches and having to rebase every two weeks, but now you implemented in a way that wasn't discussed on the review, didn't mention authors...

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

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

...or JIT? At fist I though to put the logic at 'lib/Target/PowerPC/PPCJITInfo.cpp', but from what I could understand the 'relocate' function method is indeed just to operate on the relocation addresses, not to change the upcode. Any advices/tips/suggestion would be appreciated. -- Adhemerval Zanella Netto Software Engineer Linux Technology Center Brazil Toolchain / GLIBC on Power Architecture azanella at linux.vnet.ibm.com / azanella at br.ibm.com +55 61 8642-9890

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

Hi all, I observe that r220932 (Removing the static initializer in ManagedStatic.cpp by using llvm_call_once to initialize the ManagedStatic mutex.) is causing tablegen to segfault in PPC platforms during static initialization. The crash happens while calling std::call_once introduced by this patch in the wrapper used in getManagedStaticMutex. I understand this call is buggy for some platforms

.... We did, and you re-wrote it and committed without asking the original author. So, the plan is to wait for you to finish the initial implementation alone? Again? What do we do in the interim? How many times are we going to go through this? I have waited 2 years before LLD was barely useful, then Adhemerval implemented the AArch64 back-end. Then you destroyed and now we have waited another year, but we're still unable to collaborate. If anything, now it's even harder than it was last year. Why can't we help with the design, too? We know about ARM and AArch64, that's what we do, and we...

...rb it, but openly and actively promote more collaboration by allowing other people to participate in the design and implementation of their own targets? If the former, than I'll respectfully move to MCLinker. If the latter, than I expect due process and future collaborations, including letting Adhemerval complete the AArch64 TLS implementation with proper code review, not bypass re-writes. As I said earlier, we'll continue to collaborate on LLD for the time being on both ARM and AArch64 targets, and the next months will be a test of how the LLD community will respond to this incident. Peter S...

...kel > <hfinkel at anl.gov>, azanella at linux.vnet.ibm.com > Date: 11/04/2014 11:45 AM > Subject: Re: Issue with std::call_once in PPC64 platform > > Hi Samuel, > > I haven't encountered this problem. What gcc/libstdc++ are you using? > BE or LE? > > Copying Adhemerval in case he has heard of any related issues. > > Thanks, > Bill > > On Mon, 2014-11-03 at 20:19 -0500, Samuel F Antao wrote: > > Hi all, > > > > I observe that r220932 (Removing the static initializer in > > ManagedStatic.cpp by using llvm_call_once to initiali...

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

...haviour around LLD, which is less so in the rest of the LLVM projects. The obliteration of the old ELF back-end was discussed only between a few people, not on the list. The technical reasoning could have been solid for a new back-end, but not for destroying fresh code. The removal was weeks after Adhemerval had LLD bootstrapping Clang on AArch64 upstream. There were backlashes to that decision, as well as other decisions in this list, and many people have already demonstrated discontent with how LLD patches and decisions are handled. During EuroLLVM's LLD presentation, a lot of people asked tech...

...out even notifying the original authors? I don't know how you work at your company, but this is not how open source development works. This is not the first time either that you step over people's toes with your "design decisions" that you don't share with anyone. Last year, Adhemerval has worked for three months to get the LLD AArch64 back-end working and out of the blue, no warning, the whole back-end was yanked. It doesn't matter if it was the right decision or not in the long term, we don't just yank things, especially not before some deliberation on the list. See ho...