On Sat, Nov 14, 2009 at 04:16:58PM +0000, Colin Paul Adams wrote:
Goetz> Until now I had no time and energie to dig deeper into the Goetz> problem [1], that looks to me, like rts/Linker cannot load Goetz> any object file that references errno.
Seems to be worse when I try to build snapshot ghc-6.13.20091111. I get a relocation error much earlier during the stage2 build.
Goetz> My guess is, that for dragonflys "extern __thread int Goetz> errno;" we do not only need to add a new case in Goetz> rts/Linker.c but also need to generate different code for Goetz> this thread local storage access.
I am still not sure, but the generated code might be ok 001e5565 <__hscore_get_errno>: 1e5565: 55 push %ebp 1e5566: 89 e5 mov %esp,%ebp 1e5568: 65 a1 00 00 00 00 mov %gs:0x0,%eax 1e556e: 8b 15 00 00 00 00 mov 0x0,%edx 1e5574: 8b 04 10 mov (%eax,%edx,1),%eax 1e5577: c9 leave 1e5578: c3 ret The corresponding relocation info is 001e5570 R_386_TLS_IE errno
Goetz> [1] $ ghci GHCi, version 6.10.4: Goetz> http://www.haskell.org/ghc/ :? for help Loading package Goetz> ghc-prim ... linking ... done. Loading package integer Goetz> ... linking ... done. ghc: Goetz> /var/tmp/isenmann/ghc-6.10.4-3/lib/ghc-6.10.4/base-4.1.0.0/HSbase-4.1.0.0.o: Goetz> unhandled ELF relocation(Rel) type 15
Goetz> Loading package base ... linking ... ghc: unable to load Goetz> package `base'
After some googling, and learning very little, I speclated that simply adding a third line for R_386_TLS_IE with the same action as the first line - just storing value, might work:
case R_386_TLS_IE: *pP = value; break;
This seems to work up to a point. That is I get no crashes in ghci.
I have also tried this, but I do not believe, that something that simple will work. At least it should pass this test: When you try to open a file that does not exist Prelude> System.IO.openFile "xxx" System.IO.ReadMode you should get *** Exception: xxx: openFile: does not exist (No such file or directory) and not (Unknown error: ...). My current strategie is, to avoid the problem in a first step. With the attached errno_ptr.{h,c} I create a shared library, that encapsulates the errno access, install the header file as /usr/pkg/include/errno_ptr.h and the shared lib as /usr/pkg/lib/liberrno_ptr.so Building ghc-6.10.4 with the attached patch (only a quick hack, to check the idea) I get a result, that looks much better. @Colin: Maybe you can test and use this hack. @Simon: I am not sure, in which direction I should look for solving this problem: 1. Avoid the tls problem a) Try to convince the dragonfly people, that it might be useful, to have something like the errno access wrapper in libc. b) If (1a) fails, try to create a patch for netbsd pkgsrc and/or ghc, so that an access wrapper will be created and installed as part of a ghc installation on dragonfly. 2. Fix the problem a) Try to add the necessary logic into the ghc runtime. b) Try to use the platforms loader. Have no clue, if and how (2a) or (2b) are possible, where to get some help or at least the necessary information. Goetz