similar to: [LLVMdev] [patch] add support for PIC on linux x86-64

On Fri, 2008-06-06 at 17:08 +0100, Rafael Espindola wrote: > 2008/6/6 Anton Korobeynikov <asl at math.spbu.ru>: > > Hello, Rafael > > > > Awesome! But... -ENOPATCH :( > > Attached now. Hi Rafael, Thanks a lot for working on this! I have one question about the patch; why did you choose too add a new enum, PICCallStyle, instead of reusing (possibly with some

2008/6/6 Anton Korobeynikov <asl at math.spbu.ru>: > Hello, Rafael > > Awesome! But... -ENOPATCH :( Attached now. Thanks, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047 -------------- next part -------------- A non-text attachment was scrubbed... Name: x86-64-plt.patch Type:

On Jun 6, 2008, at 11:55 AM, Dan Gohman wrote: > On Fri, 2008-06-06 at 17:08 +0100, Rafael Espindola wrote: >> 2008/6/6 Anton Korobeynikov <asl at math.spbu.ru>: >>> Hello, Rafael >>> >>> Awesome! But... -ENOPATCH :( >> >> Attached now. > > Hi Rafael, > > Thanks a lot for working on this! > > I have one question about the

I have been playing a bit with LLVM again and it looks like the current major missing feature on Linux x86-64 is PIC. Is anyone working on it? If not, I would like to do so. I have the ABI documentation (http://www.x86-64.org/documentation/abi.pdf), but would be glad if someone had some LLVM specific pointers. For example, from the targets that do have support for PIC, which one is the one to be

Hello, Rafael > On linux X86_64, calls to local but externally visible functions > should use the PLT. Access to local (same compilation unit), variables > can just use RIP relative access. Right, this is just optimization. AFAIR, current code already does this for 'normal' PIC - it just checks for linkage and doesn't assemble call via PLT for stuff with internal linkage.

For some time now the gold linker has support for plugins and llvm has a plugin for it. Unfortunately, it was still not possible to do fully transparent LTO on linux because ar had no support for plugins and a library created with llvm files in it would have no symbol table and would be rejected by gold. Today support for plugins has been committed to BFD. That is the file format abstraction

My nightly tester on x86_64-unknown-linux-gnu failed to bootstrap llvm-gcc today: Comparing stages 2 and 3 Bootstrap comparison failure! ./build/read-rtl.o differs The updates since the last bootstrap (24 hours before): went from revision 53904 to revision 53950. Ciao, Duncan.

Hello, I am trying to bootstrap on ARM linux EABI using a qemu chroot to better test my changes on at least one more architecture. I am using the following configure line: ../gcc/configure --prefix=/home/espindola/install/ --program-prefix=llvm- --enable-languages=c --disable-shared --disable-multilib --enable-llvm=/home/espindola/build --enable-checking arm-linux-gnueabi The bootstrap fails

2008/7/23 Duncan Sands <baldrick at free.fr>: > My nightly tester on x86_64-unknown-linux-gnu failed > to bootstrap llvm-gcc today: > > Comparing stages 2 and 3 > Bootstrap comparison failure! > ./build/read-rtl.o differs I am having the same problem. It was "introduced" by revision 54811, so it looks like a memory corruption problem. Investigating. > The

Yes,it's indeedly the correct one,and new ld can also support -plugin option,I don't know the reason of the trouble, 2009/9/17 Rafael Espindola <espindola at google.com> > > llvm-gcc -use-gold-plugin a.a b.o -o hello > > > > which is similar with the example in the document,it tells me that > > libLLVMgold.so can not be found ,but I truly put it in the

> I encountered the same error and the nice people from the llvm > irc-channel suggested the attached patch. It enables compiling llvm-gcc > for me, but i have not yet done any further testing and i also have no > idea if this is the right way to fix the problem. Nice. I will give it a try. I was trying to reduce a test case, but it is a bit hard. I have a cpp that crashes cc1plus,

On 27/07/07, Evan Cheng <evan.cheng at apple.com> wrote: > Code generator shouldn't introspect the LLVM type at all, except to > get the size of the type. Anything needed should be encoded by the > front-end. In the short term, please focus on getting parity with > what we already have. This means x86-64 will be wrong, but it > already is. As a second step we can then

Hi,all I'm using ubuntu8.04 and I'm installing gold-plugin along with the document of that, After I built the binutils and LLVM with plugin enabling,and I also replace ld with ld-new which supports plugin,I tried to compile a hello world program by this: llvm-gcc -use-gold-plugin a.a b.o -o hello which is similar with the example in the document,it tells me that libLLVMgold.so can not

On Jan 20, 2009, at 12:45 AM, Török Edwin wrote: > On 2009-01-20 08:01, Bill Wendling wrote: >> I'll need some more information than this. I don't have a Linux box, >> so I can't tell. Do you have a .i file? How is autoconf being >> confused? What does config.log say about it? >> >> > I've seen this failure on my nightly builder too (SVN r62521),

Hi, I am new to LLVM and have been trying to get it working on scratchbox (ARM target). When I try to build llvm-2.1, the build freezes with the following output.. /scratchbox/compilers/arm-softfloat-linux-gcc-3.4.4-cs-2005q3-2-glibc-2.3.6/bin/sbox-arm-softfloat-linux-gnu-nm: 'libgcc/./_dvmd_lnx_s.o': No such file mv -f libgcc/./_dvmd_lnx.visT libgcc/./_dvmd_lnx.vis

In order to the code generators to lower functions arguments that have the "byval" attribute, they would have to access the original argument Type. For example, on linux x86_64 {i64, i64} should be passed on registers and {i64, i64, i64} goes on the stack. The problem is that when looking at (for example) FORMAL_ARGUMENTS, the only thing that is present is the type of the pointer itself

On 2009-01-20 08:01, Bill Wendling wrote: > On Jan 19, 2009, at 5:34 PM, John Regehr wrote: > > >> Since yesterday I've been getting the error below when building llvm- >> gcc >> on Ubuntu Hardy on x86. For some reason, several instances of >> autoconf >> are getting confused and failing to detect a stdlib.h. >> >> John >>

Dear All, Currently the load of llvm.org is too high. This influences the whole project services like buildbots, bugzilla, etc. It was found that this workload is possible caused by massive mirroring of LLVM SVN repository into git/hg/whatever. Please don't do that :) 1. Usually one don't need full history, this makes the mirroring much easier and faster (do you *really* need r5000? I

> I propose that structures that are passed on registers should be slip > into many DAG level arguments (for now this would be all structs) and > the DAG should contain copies instead of loads. The nice thing about > this proposal is that for structures that are passed on the stack, the > DAG doesn't need to know the size. All that we need to add to add to > the DAG is a flag

Rafael, Remember that the qemu <= 0.9.0 can misexecute code compiled by LLVM. I think you should test using qemu CVS. Lauro 2007/11/2, Rafael Espindola <espindola at google.com>: > Hello, > > I am trying to bootstrap on ARM linux EABI using a qemu chroot to > better test my changes on at least one more architecture. > > I am using the following configure line: >