We really should support PIC codegen for Linux. Probably, we need to add additional entry to TargetData to distinguish pic & non-pic codegen (propagating -fPIC flag from llvm-gcc). It seems, that X86/Darwin codegen is already PIC (everything there is PIC), so, this code should be inspected. Also, ELF-specific codegen (GOT, PLT) should be introduced. This will allow us to build rather complex applications, e.g. mozilla/seamonkey.
This would be a great thing to have. PIC shouldn't be encoded in target data, it should just be keyed off the relocation model in llc.
Yep. I've just didn't look into darwin code before writing this report (as for targetdata). Probably, I'll have some time to implement this in the mid/end Jan.
Mine. This is not enhancement, but missing feature. Note, that 1006 also depends on this bug.
makes sense to me!
I've sent patches to: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070101/042114.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070101/042141.html These patches was tested on applications from llvm-test and worked fine. Also, I've tried to compile Qt on Linux as shared libraries set. Everything was ok, except some bizarre linker errors on some objects (they can be unrelated to patches itself). Probably, patches should be commited after review. After, remaining linker issues should be resolved as well.
All linker issues have gone after http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070101/042142.html Qt is happy now. Probably, the same patch should be applied to PPC Codegen as well.
Just found some incorrect PIC codegen. Will investigate. Patches should be fixed.
The problem was investigated. The library in question was recent Qt 4.2.2. I've built it as shared library. For test I use tiny "qdbuscpp2xml" tool from the same Qt distribution. Problem: binary crashed in the early intiailization (e.g. running static ctors in libQtCore4.so). Crash occured very early, at the first call to "_Znwj" (unmangled - "new") routine. However, gcc-compiled "qdbuscpp2xml" binary runs ok (with llvm-compiled Qt library). The differences were: 1. Different compiler. This shouldn't be the problem, since the same binary works ok linked with static library. 2. Different libstdc++/other libraries. As everything is ok with static linking I've started with dynamic linker "debugging". I've got outputs from "LD_DEBUG=all qdbuscpp2xml" and tried to compare them. It seems, that I've found the actual problem (part of logs): 1. gcc-compiled binary 32345: symbol=__cxa_atexit; lookup in file=/lib/libc.so.6 [0] 32345: binding file ../lib/libQtCore.so.4 [0] to /lib/libc.so.6 [0]: normal symbol `__cxa_atexit' [GLIBC_2.1.3] 32345: symbol=_Znwj; lookup in file=qdbuscpp2xml [0] 32345: symbol=_Znwj; lookup in file=../lib/libQtDBus.so.4 [0] 32345: symbol=_Znwj; lookup in file=/usr/lib/libdbus-1.so.3 [0] 32345: symbol=_Znwj; lookup in file=../lib/libQtXml.so.4 [0] 32345: symbol=_Znwj; lookup in file=../lib/libQtCore.so.4 [0] 32345: binding file ../lib/libQtCore.so.4 [0] to ../lib/libQtCore.so.4 [0]: normal symbol `_Znwj' 2. llvm-compiled binary 32347: symbol=__cxa_atexit; lookup in file=/lib/libc.so.6 [0] 32347: binding file ../lib/libQtCore.so.4 [0] to /lib/libc.so.6 [0]: normal symbol `__cxa_atexit' [GLIBC_2.1.3] 32347: symbol=_Znwj; lookup in file=./qdbuscpp2xml [0] 32347: binding file ../lib/libQtCore.so.4 [0] to ./qdbuscpp2xml [0]: normal symbol `_Znwj' Note, in the second case shared library external was linked to non-PIC version of the routine! As it seems to me, that we really should support different visibility levels.
Maybe, I was wrong speaking about problem source in visibility levels. Actually, qdbuscpp2xml was linked with static version of libstdc++ (due to lack of aliasing). This also can be the problem.
These series of patches implements PIC codegen for Linux/X86 & visibility support: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070108/042551.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070108/042548.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070108/042549.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070108/042550.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070108/042553.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070108/042552.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070108/042557.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070108/042556.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070108/042555.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070108/042554.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070108/042558.html Bug will be closed as soon Qt will be fine in shared mode. Probably, this will happen with aliases support (PR1006)
Shouldn't this bug be closed? We already have one for aliases support (PR1006).
Well, actually I have Qt crashed here (as I've described). Probably, this is due to lack aliases. However, I'm not sure. Ok. I'll close the bug and reopen, if there will still be some problems.
There was bug, which prevented Qt from running... Fixed with these patches: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070115/042840.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070115/042838.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070115/042839.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070115/042841.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070115/042842.html Now Qt runs fine being built in "shared" mode. The next big step is Mozilla.... :)
nice!!