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

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

> Yes, please remove PICCallStyle and have printPLT check for pic > relocation model and Subtarget.isTargetELF(). Done. > And where you are modifying this part of the code. Please rename > printGOT, printStub, and printPLT to something that indicates they are > predicate functions. Perhaps shouldPrintGOT, etc.? Done. Updated patch attached. > Thanks, > > Evan Cheers,

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:

I know I am just back from vacations, but I am sorry to inform I will be out for some time. I am changing jobs here at Google and for some time I will have to do a bit of both. This would make it hard for me to keep track of a very vivid project like LLVM. The good news Is that this should last no more the 4 months from now and that I am moving to a software developer position that should be a

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

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

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

That's pretty awesome! Will ar, etc. eventually get some autodiscovery of plugins so that things work OOTB after a make install of llvm/llvm-gcc? - Daniel On Tue, May 26, 2009 at 10:52 AM, Rafael Espindola<espindola at google.com> wrote: > For some time now the gold linker has support for plugins and llvm has > a plugin for it. > > Unfortunately, it was still not possible

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

On 21/01/2008, Arvind Ayyangar <arvind.ayyangar at gmail.com> wrote: > 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.. > I have build llvm inside scratchbox sometime ago. More recently Lauro pointed out that one should use a patched qemu. Not sure

The attached patch permits setting the LDFLAGS variable in the call to configure. This is the behavior of configure on gcc trunk. Not sure why llvm-gcc is different. This is necessary for building llvm-gcc in cases where some libraries are in strange places: CPPFLAGS="-I/foo/include" LDFLAGS="-L/foo/lib" configure .... Cheers, -- Rafael Avila de Espindola Google Ireland

> Makes sense to me. If you built with and without LDFLAGS enabled > should probably just commit it - or do you need someone to commit for > you? I can commit it. I was just not sure if this was an intentional difference. I am running a bootstrap without a LDFLAGS. Will commit if it pass. > -eric > _______________________________________________ > LLVM Developers mailing list

> 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

On May 26, 2009, at 10:52 AM, Rafael Espindola wrote: > Today support for plugins has been committed to BFD. That is the file > format abstraction library used by binutils. This now works Very nice Rafael! Can you please update the web page to mention this, e.g. in the LinkTimeOptimization.html document and wherever else relevant? -Chris > > $ llvm-gcc -emit-llvm -O2 -c a.c

> 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 directory > which is the same as the cc1's. > > What's the problem with my libLLVMgold.so's position? That looks correct. Can you check that *) It is the correct cc1 :-) (run llvm-gcc with

2009/9/17 Nan Zhu <zhunansjtu at gmail.com>: > Yes,it's indeedly the correct one,and new ld can also support -plugin > option,I don't know the reason of the trouble, Does ld actually work if you pass libLLVMGold.so to it? Try to link with llvm-gcc without the -use-gold-plugin option and with -v (it will fail as expected). Copy the collect2 line and add the -plugin line. If

> This does not bound us to any particular size promotion. The solution is generic enough to address all possibilities (of course new attributes may be needed) We are both trying to do the same, I just don't see why this can't be done completely in llvm-gcc or clang. Do you have an C example where we currently do sign extension and that we would be able to avoid it with your proposal?

2009/7/12 Daniel Dunbar <daniel at zuster.org>: > That's pretty awesome! Thanks! > Will ar, etc. eventually get some autodiscovery of plugins so that > things work OOTB after a make install of llvm/llvm-gcc? The bfd library (used by ar and nm) already searches for plugins in $install_dir/lib/bfd-plugins/. Maybe we could pass an option to llvm's configure to tell it where

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

> I am having the same problem. It was "introduced" by revision 54811, > so it looks like a memory corruption problem. Investigating. Interesting. Bootstrapping with gcac works! Some tests with valgrind also work. My next try is to add some debug code to do bounds checking in SmallVector. Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 |