assigned to @asl

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 (#1006 )

Shouldn't this bug be closed? We already have one for aliases support (#1006 ).

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

mentioned in issue llvm/llvm-bugzilla-archive#1085