Re: [HOpenGL] renderString not working in ghci
On 01/06/2009 23:39, Sven Panne wrote: So my question is again: Why is -fPIC not the default for GHC on x86_64? If we don't want the overhead, that's OK (any benchmark numbers?), but then GHC's documentation should really contain a big, fat warning that GHCi's dynamic linker gets cases like the one above wrong. There is a ticket, BTW: http://hackage.haskell.org/trac/ghc/ticket/781 I've milestoned it for 6.12.1 and made it high priority. I think the only reason that -fPIC is not the default right now on x86_64 is that (a) it's (still) experimental, and (b) we don't know what performance implications it has. Duncan will hopefully be able to resolve both in due course. Duncan: just to clarify, the problem here is that in the x86_64 small memory model (the default), external references from non-PIC code are assigned 32-bit addresses. ld.so makes this work in two ways: * if the symbol points to code, then a jump trampoline is installed in the PLT, and the 32-bit address points to it * if the symbol points to data, then the data object is moved with the dreaded R_COPY relocation, so that it ends up within the low 2Gb and the 32-bit relocation is large enough. the problem is that in GHCi's linker we don't know which symbols point to data and which point to code. So we assume they point to code (data is quite rare), and install trampolines. If we use -fPIC, then external references are made via the PLT or GOT, and the problem doesn't occur. I mentioned this in a comment on #1876: http://hackage.haskell.org/trac/ghc/ticket/1876#comment:11 One thing we could do to help would be to spot foreign import ccall foo foo :: Ptr T where T is not a function type, and emit a warning suggesting the use of -fPIC. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [HOpenGL] renderString not working in ghci
[ Reprise of an old GHCi problem, GHC HQ read on please... ] Am Mittwoch, 20. Mai 2009 09:24:14 schrieb Matthijs Kooijman: I've been playing around with GLUT (latest version from hackage, on Debian) a bit yesterday and am having some troubles with renderString. It works fine when I compile a binary using ghc, but when running from ghci I get an error similar to the following (I don't have the actual error at hand atm). freeglut(interactive): font 0xsomething not found From looking at the freeglut code, it seems this means that the font pointer passed in does not match the address of any of the font variables in the library. I'm not completely sure how the linking works in ghci, but it appears that something goes wrong with dynamic linking? Is this a known problem, or does anyone have any pointers where to debug this? After thinking about this for a while, I got a déjà vu feeling and browsed through old mails, and there it was, the thread about the arcane, dark corners of dynamic linking and position independent code, where (almost) no man has gone before: ;-) http://www.haskell.org/pipermail/cvs-ghc/2007-September/038458.html I think that we finally came to the conclusion that we *have* to compile code with -fPIC on some platforms, including x86_64, but looking at the verbose output of the build step of the GLUT package on x86_64, one can see that there is nothing PIC-related at all. Adding --ghc-option=-fPIC to Cabal's build step for the GLUT package makes ARBOcclude.hs (and renderString in general) work again. So my questing is: Is this a bug in GHC, i.e. should it always use -fPIC implicitly? Or is this a bug in my GLUT package's .cabal file? I have a tendency to believe the former possibility... Or asked the other way round: Is there a reason why -fPIC is not the default for GHC? Cheers, S. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [HOpenGL] renderString not working in ghci
On Mon, 2009-06-01 at 20:05 +0200, Sven Panne wrote: [ Reprise of an old GHCi problem, GHC HQ read on please... ] Am Mittwoch, 20. Mai 2009 09:24:14 schrieb Matthijs Kooijman: I've been playing around with GLUT (latest version from hackage, on Debian) a bit yesterday and am having some troubles with renderString. It works fine when I compile a binary using ghc, but when running from ghci I get an error similar to the following (I don't have the actual error at hand atm). freeglut(interactive): font 0xsomething not found From looking at the freeglut code, it seems this means that the font pointer passed in does not match the address of any of the font variables in the library. I'm not completely sure how the linking works in ghci, but it appears that something goes wrong with dynamic linking? Is this a known problem, or does anyone have any pointers where to debug this? After thinking about this for a while, I got a déjà vu feeling and browsed through old mails, and there it was, the thread about the arcane, dark corners of dynamic linking and position independent code, where (almost) no man has gone before: ;-) http://www.haskell.org/pipermail/cvs-ghc/2007-September/038458.html I don't know how the problem reported in that message is related to the renderString problem (which I do not understand), but the behaviour you see there is not terribly surprising. It's an artefact of the way dynamic linking works and should not generally cause any problems. The only case where it should make a difference is if code is assigning any meaning to the address of functions, eg to compare them for identity. In that case going via a thunk will make a difference. Is that what freeglut is doing do you think? I think that we finally came to the conclusion that we *have* to compile code with -fPIC on some platforms, including x86_64, but looking at the verbose output of the build step of the GLUT package on x86_64, one can see that there is nothing PIC-related at all. Adding --ghc-option=-fPIC to Cabal's build step for the GLUT package makes ARBOcclude.hs (and renderString in general) work again. So my questing is: Is this a bug in GHC, i.e. should it always use -fPIC implicitly? I rather suspect it's freeglut doing something dubious with comparing function pointers. Or is this a bug in my GLUT package's .cabal file? I have a tendency to believe the former possibility... Or asked the other way round: Is there a reason why -fPIC is not the default for GHC? On most platforms -fPIC imposes some overhead and so it is only used when it's advantageous or necessary. On most platforms code that will live in a shared library should or must be compiled with -fPIC. x86-64 is one of the few architectures where the overhead is relatively low. Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [HOpenGL] renderString not working in ghci
Am Montag, 1. Juni 2009 22:48:56 schrieb Duncan Coutts:
I don't know how the problem reported in that message is related to the
renderString problem (which I do not understand), but the behaviour you
see there is not terribly surprising. It's an artefact of the way
dynamic linking works and should not generally cause any problems.
The word generally is a problem in itself. ;-) The main point is that GHCi'l
dynamic linker behaves differently from the system's dynamic linker, so this
is a very good reason to consider this a bug. It might not surface very often,
but it is nevertheless a different behaviour a.k.a. bug.
The only case where it should make a difference is if code is assigning
any meaning to the address of functions, eg to compare them for
identity. In that case going via a thunk will make a difference. Is that
what freeglut is doing do you think?
It is not about the address of functions, it is about data addresses. Here is
the relevant snippet from GLUT's/freeglut's header file for non-Windows
platforms:
--
/*
* I don't really know if it's a good idea... But here it goes:
*/
extern void* glutStrokeRoman;
extern void* glutStrokeMonoRoman;
extern void* glutBitmap9By15;
...
/*
* Those pointers will be used by following definitions:
*/
# define GLUT_STROKE_ROMAN ((void *) glutStrokeRoman)
# define GLUT_STROKE_MONO_ROMAN ((void *) glutStrokeMonoRoman)
# define GLUT_BITMAP_9_BY_15 ((void *) glutBitmap9By15)
...
--
As you can see, GLUT's fonts are represented by the addresses of global
variables. This might not be the nicest way to do this, but it has to be done
for binary compatibility reasons and there is *nothing* dubious about this.
Note that e.g. we are very lucky that errno is a macro for a function call
on all platforms for which -fPIC is relevant, otherwise we would have the same
problem with it, too.
The GLUT Haskell package uses a simple C wrapper around these macros:
--
void*
hs_GLUT_marshalBitmapFont(int fontID)
{
switch (fontID) {
case 0 : return GLUT_BITMAP_8_BY_13;
case 1 : return GLUT_BITMAP_9_BY_15;
case 2 : return GLUT_BITMAP_TIMES_ROMAN_10;
case 3 : return GLUT_BITMAP_TIMES_ROMAN_24;
case 4 : return GLUT_BITMAP_HELVETICA_10;
case 5 : return GLUT_BITMAP_HELVETICA_12;
case 6 : return GLUT_BITMAP_HELVETICA_18;
}
return (void*)0;
}
--
For reasons explained in great length in the mail thread quoted, GHCi's linker
doesn't link the wrapper correctly on some platforms when -fPIC is not used
for its compilation.
I rather suspect it's freeglut doing something dubious with comparing
function pointers.
The only one doing dubious things is GHCi's dynamic linker... ;-)
On most platforms -fPIC imposes some overhead and so it is only used
when it's advantageous or necessary. On most platforms code that will
live in a shared library should or must be compiled with -fPIC. x86-64
is one of the few architectures where the overhead is relatively low.
So my question is again: Why is -fPIC not the default for GHC on x86_64? If we
don't want the overhead, that's OK (any benchmark numbers?), but then GHC's
documentation should really contain a big, fat warning that GHCi's dynamic
linker gets cases like the one above wrong.
Cheers,
S.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
