On 06/11/2009 23:25, Goetz Isenmann wrote:

On Wed, Nov 04, 2009 at 03:08:27PM +0000, Colin Adams wrote:

...

When GHC 6.12.1 is released, I'm going to have a go at porting it to DragonFly BSD (32-bit incarnation). Is the porting page on the wikiup-to-date?

Maybe you could start with something like:

$ curl -o ghc-6.10.4-3.tar.bz2 \ ; http://www.goetz-isenmann.de/dfly/ghc-6.10.4-3.tar.bz2 $ curl -o cabal http://www.goetz-isenmann.de/dfly/cabal $ tar xzf ghc-6.10.4-3.tar.bz2 -C /var/tmp/isenmann $ PATH=/var/tmp/isenmann/ghc-6.10.4-3/bin:$PATH $ ./cabal update $ ./cabal install --user cabal-install

I have just recompiled this ghc with itself using the attached patches and --prefix=/var/tmp/isenmann on dragonfly 2.4.1 (32bit).

The patches are only a stupid "do the same for dragonfly as for freebsd" with two exceptions AFAIR: (a) use -pthread not -lthr, and (b) this -D_POSIX_VERSION=199309 in rts/Makefile, that's most probably the wrong way to fix a (can't remember the details) build problem.

Until now I had no time and energie to dig deeper into the problem [1], that looks to me, like rts/Linker cannot load any object file that references errno.

My guess is, that for dragonflys "extern __thread int errno;" we do not only need to add a new case in rts/Linker.c but also need to generate different code for this thread local storage access.

Great work. I've added Dragonfly BSD to the list of Tier 2 platforms: http://hackage.haskell.org/trac/ghc/wiki/Platforms Would you be willing to be the maintainer for GHC on Dragonfly? We should get these patches into GHC. Most of them look straightforward, but I'm slightly suspicious of this: -STANDARD_OPTS += -DCOMPILING_RTS +STANDARD_OPTS += -DCOMPILING_RTS -D_POSIX_VERSION=199309 why was that necessary? Cheers, Simon

On November 9, 2009 12:39:25 Goetz Isenmann wrote:

On Mon, Nov 09, 2009 at 10:44:47AM +0000, Simon Marlow wrote:

...

We should get these patches into GHC. Most of them look straightforward, but I'm slightly suspicious of this:

-STANDARD_OPTS += -DCOMPILING_RTS +STANDARD_OPTS += -DCOMPILING_RTS -D_POSIX_VERSION=199309

why was that necessary?

Good that you ask. Can't remember why it was necessary back in april to build ghc-6.10.2 on dragonfly-2.2.1. Cannot reproduce the problem today with ghc-6.10.4 on dragonfly-2.4.1.

I am glad, that we do not need this define any more. I think it was a ugly workaround at best.

I'm not sure about dragonfly, but there are a bunch of similar options for glibc under Linux. For example, "man feature_test_macros" says you need to define _POSIX_C_SOURCE to 199309 or greater to use POSIX.1b functionality. Cheers! -Tyson

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

On 15/11/2009 12:42, Goetz Isenmann wrote:

@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.

You can write an access wrapper for errno, compile it into a .so shared object, and have GHCi load the .so.

2. Fix the problem a) Try to add the necessary logic into the ghc runtime.

Have a look at what the system's linker does to resolve this reference: compile a C program, load it up into gdb, and disassemble the code.

b) Try to use the platforms loader.

See above. Also when we have a dynamically linked GHCi this problem will partly go away for you (http://hackage.haskell.org/trac/ghc/ticket/3658). Cheers, Simon

On November 15, 2009 07:42:46 Goetz Isenmann wrote:

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

...

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.

According to "ELF Handling For Thread-Local Storage", R_386_TLS_IE "resolves to the absolute address of the GOT [global offset table] slot" that is assigned to the TLS (thread local storage) symbol. http://people.redhat.com/drepper/tls.pdf (middle of page 37) The GOT slot is assigned a R_386_TLS_TPOFF relocation for the symbol. So, what you are suppose to get is: 1- While linking, the linker resolves the R_386_TLS_IE relocation by updating the instruction with the absolute address of the corresponding GOT slot. 2- While loading, the dynamic linker resolves the R_386_TLS_TPOFF relocation by updating the GOT slot to contain the offset of the symbol relative to the TLS pointer (which is stored at %gs:0x0). 3- The program then computes the address of the TLS variable by loading the TLS pointer (the "mov %gs:0x0,%eax" instruction) and adding to it the symbols TLS offset as stored in the GOT table (the updated "mov 0x0,%edx" instruction). Cheers! -Tyson

On Thu, Nov 26, 2009 at 08:38:35PM +0200, Aycan iRiCAN wrote:

Sorry, are there any advancements in dragonflybsd port of ghc?

I am still using the patches and the errno access wrapper, that were attached to my last message. If you need a bootstrap compiler, you can download http://www.goetz-isenmann.de/dfly/ghc-6.10.4-dfly-5.tar.bz2, extract this into /var/tmp, download http://www.goetz-isenmann.de/dfly/liberrno_ptr.so, and put this into /usr/pkg/lib. Have not noticed any problems with this configuration so far. And since this works for me, I currently prefer to learn haskell. As time permits, I also like (a) to read about the upcoming ghc shared library support, (b) to read the tls documentation, and (c) to get something into pkgsrc, that will give use a working ghc for dragonfly But I fear, that this will not happen during the next few weeks.

On Tue, Dec 15, 2009 at 12:53 PM, Colin Paul Adams wrote:

[..snip..]

I've finally got round to trying this. I'm having a problem which maybe has a simple known solution.

What I have done so far:

1) Built and deployed the shared library as detailed above 2) Applied the diff with patch

You should use gmake instead of make.

Make immediately fails with:

"./mk/boilerplate.mk", line 41: Need an operator "./mk/boilerplate.mk", line 44: Need an operator

[..snip..]

-- Thanos Tsouanas http://mpla.math.uoa.gr/~thanos/

On Nov 14, 2009, at 11:16 , Colin Paul Adams wrote:

This seems to work up to a point. That is I get no crashes in ghci.

I do appear to have some line-feed problems. So if I type:

Prelude> let x = 10

It appears to do nothing, but that is not the case - I can then overtype with :t x and ghci responds with:

x :: Integerxx = 10 Prelude>

So maybe this is a readline/haskelline issue?

Known issue, yes, also seen on OSX. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH