ghc linker problem with __thread int errno
Markus Pfeiffer
markus.pfeiffer at morphism.de
Fri Mar 2 01:08:26 PST 2012
--ai3I8gwHc37+ASRI
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Dear all,
as of yesterday a fix for dragonfly's rtld and I have a 5 line patch
against ghc head that makes ghci and template haskell work. I successfully
compiled ghc 7.4.1 and ghc head with this.
The fix for dragonfly (which should end up in git master soon) can be
downloaded at
http://leaf.dragonflybsd.org/~profmakx/0004-rtld-tls-fix.patch
the patch against ghc's runtime linker can be downloaded
http://leaf.dragonflybsd.org/~profmakx/0001-ghc-linker-fix.patch
for ghc 7.4.1 you need another little patch for it to compile correctly. Th=
is
patch is included in Goetz' patches agains 7.0.4, but for completeness can =
be
found here
http://leaf.dragonflybsd.org/~profmakx/PosixSource.h.diff
If you find any problems, please let me know.
Markus
On Mon, Feb 20, 2012 at 01:21:04PM +0100, Goetz Isenmann wrote:
> Hi!
>=20
> Since there seems to be some interest in ghc/haskell on #dragonflybsd,
> I would like to write down, what my (uneducated) guess is about the main
> problem porting ghc to dfly.
>=20
> On dfly we have "__thread int errno", "#define errno (*__error())", and
> "static __inline int *__error(void) { return (&errno); }"
>=20
> I believe, that ghc generates correct code for this thread local (tls)
> access (uses the C comiler), but the ghc linker/load (rts/linker.c)
> cannot handle the resulting relocation types:
> #define R_386_TLS_IE 15 /* Absolute address of GOT for -ve static=
TLS */
> #define R_X86_64_GOTTPOFF 22 /* PC relative offset to IE GOT entry */
>=20
> To get an idea, what the ghc linker should do, I did this:
>=20
> $ cat >main.c
> #include <errno.h>
> int main() {
> return errno;
> }
> $ gcc -c -O main.c
> $ gcc -o main main.o
> $ objdump -d main.o
>=20
> main.o: file format elf32-i386
>=20
> Disassembly of section .text:
>=20
> 00000000 <main>:
> 0: 8d 4c 24 04 lea 0x4(%esp),%ecx
> 4: 83 e4 f0 and $0xfffffff0,%esp
> 7: ff 71 fc pushl 0xfffffffc(%ecx)
> a: 55 push %ebp
> b: 89 e5 mov %esp,%ebp
> d: 51 push %ecx
> e: 65 a1 00 00 00 00 mov %gs:0x0,%eax
> 14: 8b 15 00 00 00 00 mov 0x0,%edx
> 1a: 8b 04 10 mov (%eax,%edx,1),%eax
> 1d: 59 pop %ecx
> 1e: c9 leave =20
> 1f: 8d 61 fc lea 0xfffffffc(%ecx),%esp
> 22: c3 ret =20
> $ objdump -d main
> ...
> 08048548 <main>:
> 8048548: 8d 4c 24 04 lea 0x4(%esp),%ecx
> 804854c: 83 e4 f0 and $0xfffffff0,%esp
> 804854f: ff 71 fc pushl 0xfffffffc(%ecx)
> 8048552: 55 push %ebp
> 8048553: 89 e5 mov %esp,%ebp
> 8048555: 51 push %ecx
> 8048556: 65 a1 00 00 00 00 mov %gs:0x0,%eax
> 804855c: 8b 15 6c 96 04 08 mov 0x804966c,%edx
> -----------------------------------------------^^^^^^^^^
> 8048562: 8b 04 10 mov (%eax,%edx,1),%eax
> 8048565: 59 pop %ecx
> 8048566: c9 leave =20
> 8048567: 8d 61 fc lea 0xfffffffc(%ecx),%esp
> 804856a: c3 ret =20
> 804856b: 90 nop =20
> ...
> $ objdump -h main
>=20
> main: file format elf32-i386
>=20
> Sections:
> Idx Name Size VMA LMA File off Algn
> ...
> 17 .got 00000004 0804966c 0804966c 0000066c 2**2
> ----------------------------^^^^^^^^^^^^^^^^^^
> CONTENTS, ALLOC, LOAD, DATA
> ...
>=20
> The same on x86_64:
>=20
> $ objdump -d main.o
>=20
> main.o: file format elf64-x86-64
>=20
>=20
> Disassembly of section .text:
>=20
> 0000000000000000 <main>:
> 0: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 7 <main+0x=
7>
> 7: 64 48 8b 14 25 00 00 mov %fs:0x0,%rdx
> e: 00 00=20
> 10: 8b 04 02 mov (%rdx,%rax,1),%eax
> 13: c3 retq =20
> $ objdump -d main
> ...
> 40060c: 48 8b 05 8d 02 20 00 mov 0x20028d(%rip),%rax =
# 6008a0 <_DYNAMIC+0x170>
> -----------------------------------------------^^^^^^^^
> 400613: 64 48 8b 14 25 00 00 mov %fs:0x0,%rdx
> --^^^^^^
> 40061a: 00 00=20
> 40061c: 8b 04 02 mov (%rdx,%rax,1),%eax
> 40061f: c3 retq =20
> ...
> $ objdump -h main
>=20
> main: file format elf64-x86-64
>=20
> Sections:
> Idx Name Size VMA LMA File off =
Algn
> ...
> 18 .got 00000008 00000000006008a0 00000000006008a0 000008a0 =
2**3
> ----------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> CONTENTS, ALLOC, LOAD, DATA
> ...
> $ python2.6 -c 'print hex(0x6008a0 - 0x20028d)'
> 0x400613
>=20
>=20
> This gives me the idea, that the ghc linker should insert a pointer to
> the .got segment on i386 and insert the 32bit offset to the .got
> segment on x86_64.
>=20
> So the next point on my todo list for ghc is, to recompile ghc without
> my errno access wrapper, take the .got value from the resulting binary
> and recompile ghc again with the linker inserting this value, check
> that the .got value hasn't changed, and see what happens.
>=20
> If this goes well, the next steps would be to (a) find out, how to
> calculate the .got value inside the linker, and (b) think about an
> experiment, that could show me what has to be done, when there is more
> than one tls variable.
>=20
> Hmm, maybe I should try also from the opposite side: How important is
> this "static __inline" on the __error function?
> Are there any situations, where one would notice a performance impact?
> --=20
> Goetz Isenmann
> --=20
> Vorstand/Board of Management:
> Dr. Bernd Finkbeiner, Michael Heinrichs,=20
> Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech
> Vorsitzender des Aufsichtsrats/
> Chairman of the Supervisory Board:
> Philippe Miltin
> Sitz/Registered Office: Tuebingen
> Registergericht/Registration Court: Stuttgart
> Registernummer/Commercial Register No.: HRB 382196
>=20
--=20
Markus Pfeiffer, University of St. Andrews
email: markus.pfeiffer at morphism.de | xmpp: markus.pfeiffer at jabber.morphism.=
de
--ai3I8gwHc37+ASRI
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (FreeBSD)
iQIcBAEBAgAGBQJPUI4KAAoJEEYIAIuHgtZGLTkP/jx2ABXcQ3+Ow8/+9NMC7IqW
cQfcbdsdRxSj596+Y69GBll1EjP6mh/P3Oun1FBHZKUnJYFeW6a+UcN2n5C+MZmE
GZ8UEP1xK+IwQB+rlRlJlj03zSdkVSjQ9mCbBtm2cqa9PKoZyN1JKE8kiOoR/T8d
fl99iBXbbNFP0BQN5Pt86OIADwleMyTkCItraqmc/ygazcEe+8xZf+k004eotuDz
zXmSp63IgKZ9tuT/2Ho9zYBjzqpYopIChIoM+QogCeCOAN+Ie/2ny4D90dd9ahdG
ZFenvy06XrFiaVRJvCTLB5156q03Cf+tDTUrlOFWuokpRqOfkHEtSunx7cr6ImYi
wRcLnE7Vj8rkhcTcNMAKqhXr3igHeYSMYdDEz+JtgI3ehwBP9Ow5wAOzZhZIAD2D
YfT4jOEjy39Iwer+dDs5Ux2y9MTy/9bsSKY1KzqlzVjW8FNRw6IBXoVq/Boa6vgY
CRsimmlnX5HPtweS0cyOD4YoV6sB/kDd9Ul7HdNj5wak8T9SQCQgBrkQZTvcCKgw
fXLUTHg7trPALWL5H7V+AadAYd66LJ0og3SfkbkmwT30N09pneLSfcFh7IUZyGfN
XwF0Ki7JrT8uYsXRSwMONWYlbZEct3RgVUDisPshUIi3RtgAKKivp1Nhawrs6tRY
hTofXADWKR4x0HssDRYq
=CaP7
-----END PGP SIGNATURE-----
--ai3I8gwHc37+ASRI--
More information about the Users
mailing list