Hi all,
I noticed that now that --enable-pic is the default in svn, there's also
some logic in Makefiles.rules to eliminate -fPIC for the case of mingw
and cygwin:
ifeq ($(ENABLE_PIC),1)
ifeq ($(OS), $(filter $(OS), Cygwin MingW))
# Nothing. Win32 defaults to PIC and warns when given -fPIC
else
...
I would suggest that it should be done this way (i.e., eliminating
-fPIC) not only for win32, but for all 32 bit x86 systems. Or has anyone
seen any kind of x86 system where the -fPIC is indeed required?
The problem with using -fPIC on x86 is not only the speed of the
generated code, I also get JIT-related segfaults in the Pure interpreter
(on Linux). See, e.g.:
http://code.google.com/p/pure-lang/issues/detail?id=9
(That specific bug report relates to the Ubuntu Jaunty LLVM 2.5 package,
which is (mis)configured with --enable-pic on all architectures
including x86. But the issue is exactly the same with current svn, as
has been reported for various different x86 Linux systems by other Pure
users. The segfaults go away if LLVM is compiled with --disable-pic on
x86. I don't have a minimal test example, but I'm pretty sure that the
bug is in LLVM, not in the Pure interpreter, as the interpreter passes
its test suite just fine if LLVM is compiled with --disable-pic.)
Note that -fPIC is *not* required to build shared libraries on 32 bit
x86, in fact AFAICT it's recommended to *not* use -fPIC there. The
workaround is obvious: we just tell users to build LLVM with
--disable-pic on x86 systems (and to avoid broken binary x86 packages
like the one in Jaunty). But of course it would make things easier for
packagers and end users if this worked out of the box.
Thanks,
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Albert Graef wrote:> I noticed that now that --enable-pic is the default in svn, there's also > some logic in Makefiles.rules to eliminate -fPIC for the case of mingw > and cygwin: > > ifeq ($(ENABLE_PIC),1) > ifeq ($(OS), $(filter $(OS), Cygwin MingW)) > # Nothing. Win32 defaults to PIC and warns when given -fPIC > else > ... > > I would suggest that it should be done this way (i.e., eliminating > -fPIC) not only for win32, but for all 32 bit x86 systems. Or has anyone > seen any kind of x86 system where the -fPIC is indeed required?It's not strictly required, as the runtime system will fix them up, but of course the fixed-up parts of the "shared libraries" are no longer shared, which rather defeats the point.> The problem with using -fPIC on x86 is not only the speed of the > generated code, I also get JIT-related segfaults in the Pure interpreter > (on Linux). See, e.g.: > > http://code.google.com/p/pure-lang/issues/detail?id=9 > > (That specific bug report relates to the Ubuntu Jaunty LLVM 2.5 package, > which is (mis)configured with --enable-pic on all architectures > including x86. But the issue is exactly the same with current svn, as > has been reported for various different x86 Linux systems by other Pure > users. The segfaults go away if LLVM is compiled with --disable-pic on > x86. I don't have a minimal test example, but I'm pretty sure that the > bug is in LLVM, not in the Pure interpreter, as the interpreter passes > its test suite just fine if LLVM is compiled with --disable-pic.) > > Note that -fPIC is *not* required to build shared libraries on 32 bit > x86, in fact AFAICT it's recommended to *not* use -fPIC there.That's not true for Fedora, where non-PIC shared libraries will fail rpmlint and SELinux may (depending on how it's configured) refuse to load them. The real solution is to fix the bug. Andrew.
Albert Graef wrote:> Hi all, > > I noticed that now that --enable-pic is the default in svn, there's > also some logic in Makefiles.rules to eliminate -fPIC for the case > of mingw and cygwin: > > ifeq ($(ENABLE_PIC),1) > ifeq ($(OS), $(filter $(OS), Cygwin MingW)) > # Nothing. Win32 defaults to PIC and warns when given -fPIC > else > ... > > I would suggest that it should be done this way (i.e., eliminating > -fPIC) not only for win32, but for all 32 bit x86 systems. Or has > anyone seen any kind of x86 system where the -fPIC is indeed > required? > > The problem with using -fPIC on x86 is not only the speed of the > generated code, I also get JIT-related segfaults in the Pure > interpreter (on Linux). See, e.g.: > > http://code.google.com/p/pure-lang/issues/detail?id=9 > > (That specific bug report relates to the Ubuntu Jaunty LLVM 2.5 > package, which is (mis)configured with --enable-pic on all > architectures including x86. But the issue is exactly the same with > current svn, as has been reported for various different x86 Linux > systems by other Pure users. The segfaults go away if LLVM is > compiled with --disable-pic on x86. I don't have a minimal test > example, but I'm pretty sure that the bug is in LLVM, not in the > Pure interpreter, as the interpreter passes its test suite just fine > if LLVM is compiled with --disable-pic.) > > Note that -fPIC is *not* required to build shared libraries on 32 > bit x86, in fact AFAICT it's recommended to *not* use -fPIC > there. The workaround is obvious: we just tell users to build LLVM > with --disable-pic on x86 systems (and to avoid broken binary x86 > packages like the one in Jaunty). But of course it would make things > easier for packagers and end users if this worked out of the box.I'm not sure if it's specifically required on 32-bit x86 (and I don't have a machine lying around to test it on) but certainly on PowerPC you cannot link other shared libraries with LLVM unless you build LLVM with --enable-pic because parts of LLVM end up statically linked into the library that's linked with LLVM (there are ordinary object files listed in `llvm_config --libs`). If something is crashing in Pure/LLVM when LLVM is built with --enable-pic then surely the correct solution is to find and fix the crash, not to silently remove compiler options on certain platforms. If someone builds LLVM with --enable-pic then presumably they wanted it... Cheers, Gary -- http://gbenson.net/
Hello, Everyone> Note that -fPIC is *not* required to build shared libraries on 32 bit > x86, in fact AFAICT it's recommended to *not* use -fPIC there. The > workaround is obvious: we just tell users to build LLVM with > --disable-pic on x86 systems (and to avoid broken binary x86 packages > like the one in Jaunty).The problem is pretty easy: nobody cared about loading GOT pointer to ebx before doing a call via PLT. The initial patch for this was x86-64 only (and I explicitly mentioned that it won't work on x86-32 due to this issue). Unfortunately, it was commited as-is and later when PIC was enabled by default this subtle bug appeared... The proper solution will be to conditionalize for x86-32 linux and assemble a proper call sequence via PLT. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
Albert,> The problem with using -fPIC on x86 is not only the speed of the > generated code, I also get JIT-related segfaults in the Pure interpreter > (on Linux). See, e.g.:Please fill a PR in the LLVM bugzilla, so this issue won't get lost. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
Anton Korobeynikov wrote:>> The problem with using -fPIC on x86 is not only the speed of the >> generated code, I also get JIT-related segfaults in the Pure interpreter >> (on Linux). See, e.g.: > Please fill a PR in the LLVM bugzilla, so this issue won't get lost.Will do. Thanks for the explanation! -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag
Anton Korobeynikov wrote:>> The problem with using -fPIC on x86 is not only the speed of the >> generated code, I also get JIT-related segfaults in the Pure interpreter >> (on Linux). See, e.g.: > Please fill a PR in the LLVM bugzilla, so this issue won't get lost.Done. See http://llvm.org/bugs/show_bug.cgi?id=4275 -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag