On Monday 17 September 2007 21:56, Wolfgang Thaller wrote:
> "Something like that" is the reason. For non-PIC, ELF tries to keep
> up the illusion that there is no such thing as dynamic linking. In
> the X86_64 small code model, all addresses in the main program are
> expected to lie in the 32-bit range (+-2GB), so the assembler will
> generate a 32-bit reloc. The static linker will generate appropriate
> dynamic relocations in the final executable (see objdump -R a.out) to
> instruct the dynamic linker on how to keep up the no-dynamic-linking
> illusion.
> For code references, the static linker will allocate space for a PLT
> entry and emit a JUMP_SLOT relocation (which will be handled by the
> dynamic linker).
> For data references, the static linker will allocate space according
> to the .size directive for the symbol and emit a COPY relocation in
> the executable. The dynamic linker will then copy the initial value
> for the symbol from the dynamic library's data section, and make all
> references to the glutBitmap8By13 from libglut.so point to the new
> copy in the executable's data section rather than to the original in
> libglut.so's data section.
OK, thanks for the detailed explanation, finally I'm beginning to understand
how things like this can work at all when dynamic linking is involved.
> I am puzzled as to why dlsym seems to
> return the symbol's original address, rather than the one allocated
> within the executable's data section. This behaviour seems broken to
> me, but it also happens on my 32bit linux box. Note that dlsym( NULL,
> "glutBitmap8By13" ) == &glutBitmap8By13.
I think that this is broken, too. Slightly changed example:
-------------------------------------------------------------------------------------
#include <dlfcn.h>
#include <stdio.h>
// cut-n-paste from freeglut, used in
// #define GLUT_BITMAP_8_BY_13 ((void *) &glutBitmap8By13)
extern void* glutBitmap8By13;
int main(void) {
void *handle = dlopen("libglut.so", RTLD_NOW | RTLD_GLOBAL);
int* p1 = (int*)dlsym(handle, "glutBitmap8By13");
int* p2 = (int*)&glutBitmap8By13;
dlclose(handle);
printf("%p %p\n", p1, p2);
*p1 = 12345678;
*p2 = 87654321;
printf("%d %d\n", *p1, *p2);
return 0;
}
-------------------------------------------------------------------------------------
[EMAIL PROTECTED]:~> gcc strange.c -ldl -lglut && ./a.out
0x2b3eebc29f00 0x601040
12345678 87654321
[EMAIL PROTECTED]:~> gcc strange.c -fpic -ldl -lglut && ./a.out
0x2ad4b75a7f00 0x2ad4b75a7f00
87654321 87654321
-------------------------------------------------------------------------------------
Huh??? I think that the property
dlsym(handle, "foo") == &foo
is a very basic and important one, and I can't imagine why the behaviour above
could be "correct".
> > Now we get a R_X86_64_GOTPCREL and things work as expected. Alas,
> > our GHC
> > Linker can't handle such a relocation,
>
> That shouldn't be a lot of work. The same relocation is already
> implemented for Darwin/x86_64. [...]
Can I interpret this as: "I am willing to implement this for
Linux/x86_64"? ;-) I am not sure if I found the correct place in Linker.c
you've mentioned.
> My recommendation would be implement the PIC relocations in the ELF/
> X86_64 linker and then to require -fPIC for GHCi libs on that platform.
This seems to be the only way, it seems. :-(
On Tuesday 18 September 2007 09:58, Simon Marlow wrote:
> Yes, we even have a ticket for it:
>
> http://hackage.haskell.org/trac/ghc/ticket/781
Ooops, I forgot about that one.
> [...]
> Sven: one workaround for now is to access your data by calling a C wrapper
> function in a shared library. This is how we manage to access errno, for
> example.
Hmmm, I can't see what you mean: errno is accessed through an inline function
for compilation via C, and it is available as a plain old C funtion as well
(PrelIOUtils.c), but the latter is not in a shared library, just in a .o/.a
file (no PIC involved). This works at least for my platform because errno is
accessed via a function and is not a reference to data.
Cheers,
S.
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
