Re: ghc linker problem with __thread int errno

[Markus Pfeiffer <markus.pfeiffer@xxxxxxxxxxx>]

--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@morphism.de | xmpp: markus.pfeiffer@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--