FreeBSD/amd64 registerised running

Gregory Wright

8 Apr 2007 8 Apr '07

11:49 p.m.

Hi Ian, Simon, I have ghc-6.6 (darcs version from 20070405) running registerized on FreeBSD/amd64. The FreeBSD version is 6.2. The problem with the compiler crash turned out to be simple. In the FreeBSD header file regex.h, regex_t is defined as typedef struct { int re_magic; size_t re_nsub; /* number of parenthesized subexpressions */ __const char *re_endp; /* end pointer for REG_PEND */ struct re_guts *re_g; /* none of your business :-) */ } regex_t; The problem is that the "re_magic" field is defined as an int. When building the .hc files on the i386 host, the re_nsub field is at an offset of 4. On the amd64 target, it is at an offset of 8. In the ghc binding to the regex functions, re_nsub is used to compute how much memory to allocate in a call to allocaBytes. This leads to garbage being passed to newPinnedByteArray#. The fix is to patch libraries/base/Text/Regex/Posix.hs on the amd64 target: --- libraries/base/Text/Regex/Posix.hs.sav Thu Apr 5 12:05:22 2007 +++ libraries/base/Text/Regex/Posix.hs Thu Apr 5 12:05:45 2007 @@ -106,7 +106,7 @@ regexec (Regex regex_fptr) str = do withCString str $ \cstr -> do withForeignPtr regex_fptr $ \regex_ptr -> do - nsub <- ((\hsc_ptr -> peekByteOff hsc_ptr 4)) regex_ptr + nsub <- ((\hsc_ptr -> peekByteOff hsc_ptr 8)) regex_ptr {-# LINE 109 "Posix.hsc" #-} let nsub_int = fromIntegral (nsub :: CSize) allocaBytes ((1 + nsub_int) * (16)) $ \p_match -> do With this patch, we are pretty close. However, there still seems to be something wrong with the splitter. I can make a working registerized compiler if I set splitObjs=NO in build.mk, but it seems as if whatever is wrong with ghc-split shouldn't be too hard to fix. The splitting problem shows up as a linking failure. Some variables defined in the text section are changed from global symbols to local symbols by the splitter. An example (just one of several hundred symbols that are changed from global to local): From building ghc-6.6-20070405 on i386:

...

nm --defined-only libHSbase.a | grep "D "

<snip> 00000000 D base_TextziReadziLex_zdLr3bklvl122_closure and from building ghc-6.6-20070405 on amd64:

...

nm --defined-only libHSbase.a | grep "d "

<snip> 0000000000000000 d base_TextziReadziLex_zdLr3bklvl122_closure The "D" on i386 indicates a global symbol, the "d" on amd64 a local symbol. I've glanced at ghc-split.lprl, but on what files is it invoked? Can I run it from the command line on a file and see check what comes out? The file itself doesn't say what it expects as input, and the section of the Commentary on the splitter is more than terse. The linker is still broken (so no ghci): greenhouse-george> ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.20770405, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. ghc-6.6.20770405: internal error: R_X86_64_PC32 relocation out of range: __isthreaded = 0xfffffff800122aad (GHC version 6.6.20070405 for x86_64_unknown_freebsd) Please report this as a GHC bug: http://www.haskell.org/ghc/ reportabug Abort trap: 6 (core dumped) but I think I understand this. On FreeBSD mmap does not have the MAP_32BIT option that linux does to guarantee a mapping in first 2 GB of address space. But by supplying a hint address in the lower address space we can get the effect the MAP_32BIT option. I thought I had this fixed in the patch I applied to Linker.c, but I have obviously overlooked something. I'm continuing to work on the linker, and expect that it will be working soon. I'd appreciate a some guidance on the splitter question as I am entirely unfamiliar with it. Best Wishes, Greg

Show replies by date

Ian Lynagh

9 Apr 9 Apr

4:21 p.m.

On Sun, Apr 08, 2007 at 07:49:24PM -0400, Gregory Wright wrote:

...

I have ghc-6.6 (darcs version from 20070405) running registerized on FreeBSD/amd64.

Excellent! Well done, and thanks for persevering! It would be great if you could let us have a bindist and any necessary patches.

...

The fix is to patch libraries/base/Text/Regex/Posix.hs on the amd64 target:

--- libraries/base/Text/Regex/Posix.hs.sav Thu Apr 5 12:05:22 2007 +++ libraries/base/Text/Regex/Posix.hs Thu Apr 5 12:05:45 2007 @@ -106,7 +106,7 @@ regexec (Regex regex_fptr) str = do withCString str $ \cstr -> do withForeignPtr regex_fptr $ \regex_ptr -> do - nsub <- ((\hsc_ptr -> peekByteOff hsc_ptr 4)) regex_ptr + nsub <- ((\hsc_ptr -> peekByteOff hsc_ptr 8)) regex_ptr {-# LINE 109 "Posix.hsc" #-} let nsub_int = fromIntegral (nsub :: CSize) allocaBytes ((1 + nsub_int) * (16)) $ \p_match -> do

Aha! That makes sense: When generating .hc files on the host machine, hsc2hs makes a C program which generates a .hs module (with the host's sizes embedded in it) which is finally compiled down to .hc as normal. So I think to do this in a way that is porting-friendly, hsc2hs would have to convert f = ... #peek regex_t, re_nsub ... into something like -- Haskell: foreign import re_nsub_off :: Int f = ... (\hsc_ptr -> peekByteOff hsc_ptr re_nsub_off) ... /* C */ #import "HsFFI.h" HsInt re_nsub_off(void) { return ... } Unfortunately I don't think we can do anything as nice with #type.

...

With this patch, we are pretty close. However, there still seems to be something wrong with the splitter. I can make a working registerized compiler if I set splitObjs=NO in build.mk, but it seems as if whatever is wrong with ghc-split shouldn't be too hard to fix.

I've glanced at ghc-split.lprl, but on what files is it invoked? Can I run it from the command line on a file and see check what comes out?

If you compile a module with ghc -v -keep-tmp-files then you should see the commandline it is using, and it should leave the files for you to examine, and rerun the commands on, afterwards. Thanks Ian

Gregory Wright

4:38 p.m.

Hi Ian, On Apr 9, 2007, at 12:21 PM, Ian Lynagh wrote:

...

On Sun, Apr 08, 2007 at 07:49:24PM -0400, Gregory Wright wrote:

...
I have ghc-6.6 (darcs version from 20070405) running registerized on FreeBSD/amd64.

Excellent! Well done, and thanks for persevering!

It would be great if you could let us have a bindist and any necessary patches.

I will certainly provide patches and a binary distribution that people can use to bootstrap their own compilers. I will try to get ghci running before I put out a release.

...

If you compile a module with

ghc -v -keep-tmp-files

then you should see the commandline it is using, and it should leave the files for you to examine, and rerun the commands on, afterwards.

I'm giving this a try right now. Best Wishes, Greg

Gregory Wright

10:49 p.m.

Hi Ian, On Apr 9, 2007, at 12:21 PM, Ian Lynagh wrote:

...

...
With this patch, we are pretty close. However, there still seems to be something wrong with the splitter. I can make a working registerized compiler if I set splitObjs=NO in build.mk, but it seems as if whatever is wrong with ghc-split shouldn't be too hard to fix.

I've glanced at ghc-split.lprl, but on what files is it invoked? Can I run it from the command line on a file and see check what comes out?

If you compile a module with

ghc -v -keep-tmp-files

then you should see the commandline it is using, and it should leave the files for you to examine, and rerun the commands on, afterwards.

I did this and immediately discovered that the problem is not with ghc-split but with ghc-asm. ".globl" directives are being deleted when they shouldn't be. This is somewhat reminiscent of bug #1167, except that it seems to happen far more frequently on amd64. Perhaps someone has an idea of the top of their head for this one. I wouldn't be surprised if the fix for this also took care of the bug on the less loved linux-ppc platform. Best Wishes. Greg

Simon Marlow

10 Apr 10 Apr

10:53 a.m.

Gregory Wright wrote:

...

I have ghc-6.6 (darcs version from 20070405) running registerized on FreeBSD/amd64. The FreeBSD version is 6.2.

The problem with the compiler crash turned out to be simple. In the FreeBSD header file regex.h, regex_t is defined as

typedef struct { int re_magic; size_t re_nsub; /* number of parenthesized subexpressions */ __const char *re_endp; /* end pointer for REG_PEND */ struct re_guts *re_g; /* none of your business :-) */ } regex_t;

The problem is that the "re_magic" field is defined as an int. When building the .hc files on the i386 host, the re_nsub field is at an offset of 4. On the amd64 target, it is at an offset of 8. In the ghc binding to the regex functions, re_nsub is used to compute how much memory to allocate in a call to allocaBytes. This leads to garbage being passed to newPinnedByteArray#.

The fix is to patch libraries/base/Text/Regex/Posix.hs on the amd64 target:

--- libraries/base/Text/Regex/Posix.hs.sav Thu Apr 5 12:05:22 2007 +++ libraries/base/Text/Regex/Posix.hs Thu Apr 5 12:05:45 2007 @@ -106,7 +106,7 @@ regexec (Regex regex_fptr) str = do withCString str $ \cstr -> do withForeignPtr regex_fptr $ \regex_ptr -> do - nsub <- ((\hsc_ptr -> peekByteOff hsc_ptr 4)) regex_ptr + nsub <- ((\hsc_ptr -> peekByteOff hsc_ptr 8)) regex_ptr {-# LINE 109 "Posix.hsc" #-} let nsub_int = fromIntegral (nsub :: CSize) allocaBytes ((1 + nsub_int) * (16)) $ \p_match -> do

With this patch, we are pretty close.

Aha. Text/Regex/Posix.hs is generated from Text/Regex/Posix.hsc by hsc2hs, but this is done on the *host* rather than the *target* when bootstrapping, and thus generates the wrong results. If you'd run hsc2hs on the target, then Text/Regex/Posix.hs would have been correct, but you can't do this because hsc2hs is a Haskell program. You could take the .c file generated by hsc2hs on the host and compile/run it on the target, but that's a hassle, so instead our policy is that we don't rely on any hsc2hs-generated code for bootstrapping. Unfortunately I broke the rules by accident when I introduced the dependency on regex. I can't think of an easy way to enforce the rule, at least at the moment, since there are other hsc2hs-processed modules that we happen to not depend on in GHC (System.Time and System.CPUTime). This will be fixed as a side effect of http://hackage.haskell.org/trac/ghc/ticket/1160. Also after the base reorg we might find we have no hsc2hs-generated code left in base and we can disable hsc2hs to prevent this happening again. Cheers, Simon

Chris Kuklewicz

11:12 a.m.

Simon Marlow wrote:

...

Aha. Text/Regex/Posix.hs is generated from Text/Regex/Posix.hsc by hsc2hs, but this is done on the *host* rather than the *target* when bootstrapping, and thus generates the wrong results. If you'd run hsc2hs on the target, then Text/Regex/Posix.hs would have been correct, but you can't do this because hsc2hs is a Haskell program. You could take the .c file generated by hsc2hs on the host and compile/run it on the target, but that's a hassle, so instead our policy is that we don't rely on any hsc2hs-generated code for bootstrapping.

Unfortunately I broke the rules by accident when I introduced the dependency on regex. I can't think of an easy way to enforce the rule, at least at the moment, since there are other hsc2hs-processed modules that we happen to not depend on in GHC (System.Time and System.CPUTime).

Could the solution be to depend on a pure Haskell regex implementation instead of on a regex-posix / Posix.hsc and the system regex library? The regex-tdfa backend could be modified to work with the regex-base in GHC 6.6 and then regex-compat could quickly be switched to use this instead of regex-posix. -- Chris Kuklewicz

Simon Marlow

11 Apr 11 Apr

7:58 a.m.

Chris Kuklewicz wrote:

...

Simon Marlow wrote:

...
Aha. Text/Regex/Posix.hs is generated from Text/Regex/Posix.hsc by hsc2hs, but this is done on the *host* rather than the *target* when bootstrapping, and thus generates the wrong results. If you'd run hsc2hs on the target, then Text/Regex/Posix.hs would have been correct, but you can't do this because hsc2hs is a Haskell program. You could take the .c file generated by hsc2hs on the host and compile/run it on the target, but that's a hassle, so instead our policy is that we don't rely on any hsc2hs-generated code for bootstrapping.

Unfortunately I broke the rules by accident when I introduced the dependency on regex. I can't think of an easy way to enforce the rule, at least at the moment, since there are other hsc2hs-processed modules that we happen to not depend on in GHC (System.Time and System.CPUTime).

Could the solution be to depend on a pure Haskell regex implementation instead of on a regex-posix / Posix.hsc and the system regex library?

Yes, as I mentioned, ticket 1160 (http://hackage.haskell.org/trac/ghc/ticket/1160) is for replacing regex-posix with regex-tdfa, and that would fix this issue. However, Igloo just removed the regex packages from GHC's core package set, so we don't have the problem any more.

...

The regex-tdfa backend could be modified to work with the regex-base in GHC 6.6 and then regex-compat could quickly be switched to use this instead of regex-posix.

It sounds like a good idea to switch regex-compat to depend on regex-tdfa anyway. Cheers, Simon

Chris Kuklewicz

8:23 a.m.

Simon Marlow wrote:

...

Chris Kuklewicz wrote:

...
Could the solution be to depend on a pure Haskell regex implementation instead of on a regex-posix / Posix.hsc and the system regex library?

Yes, as I mentioned, ticket 1160 (http://hackage.haskell.org/trac/ghc/ticket/1160) is for replacing regex-posix with regex-tdfa, and that would fix this issue.

However, Igloo just removed the regex packages from GHC's core package set, so we don't have the problem any more.

...
The regex-tdfa backend could be modified to work with the regex-base in GHC 6.6 and then regex-compat could quickly be switched to use this instead of regex-posix.

It sounds like a good idea to switch regex-compat to depend on regex-tdfa anyway.

After I upgrade to 6.6.1 (using OS X on PPC) then I will make new versions of regex-compat and regex-tdfa. The thing I have to fix is that the current "unstable" regex-tdfa depends on the "unstable" regex-base and I have to make a new branch of regex-tdfa that works against the "stable" regex-base that 6.6 and 6.6.1 use. Mainly this will be erasing code. For 6.8 we can upgrade regex-base to whatever the latest version is then. Current changes in regex-base are (1) use of 'fail' for error handling in RegexMaker, (2) use of newtypes to make avoid Hugs seeing overlapping instances in RegexContext (no more conditional compilation). -- Chris

Bulat Ziganshin

5:09 p.m.

New subject: Re[2]: FreeBSD/amd64 registerised running

Hello Chris, Wednesday, April 11, 2007, 12:23:35 PM, you wrote:

...

After I upgrade to 6.6.1 (using OS X on PPC) then I will make new versions of regex-compat and regex-tdfa. The thing I have to fix is that the current "unstable" regex-tdfa depends on the "unstable" regex-base and I have to make a new branch of regex-tdfa that works against the "stable" regex-base that 6.6 and 6.6.1 use. Mainly this will be erasing code.

...

For 6.8 we can upgrade regex-base to whatever the latest version is then.

why not just provide with 6.6.1 both old and new regex-base versions? after all, the exact reason of splitting base was just to get more flexibility. anyone who need old version can use it using cabal/ghc-pkg features, one shouldn't suppose that ghc 6.6.* will forever bundle only the same versions of packages that was shipped at ancient 6.6.0 times -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Gregory Wright

1:29 p.m.

Just a further note on the FreeBSD/amd64 port. I have the mangler fixed up now, so the only remaining issue is the linker. I hope to send patches soon. Best Wishes, Greg

Malcolm Wallace

12 Apr 12 Apr

1:43 p.m.

Simon Marlow wrote:

...

Also after the base reorg we might find we have no hsc2hs-generated code left in base and we can disable hsc2hs to prevent this happening again.

Ah. I was about to checkin a replacement for System.Posix.Types (in base) that uses hsc2hs instead of autoconf. Will that cause a problem? I'm guessing that even the autoconf'd sources are currently bootstrapped on the host rather than the target, so maybe the changeover will make no difference? Regards, Malcolm

Simon Marlow

3:33 p.m.

Malcolm Wallace wrote:

...

Simon Marlow wrote:

...
Also after the base reorg we might find we have no hsc2hs-generated code left in base and we can disable hsc2hs to prevent this happening again.

Ah. I was about to checkin a replacement for System.Posix.Types (in base) that uses hsc2hs instead of autoconf. Will that cause a problem? I'm guessing that even the autoconf'd sources are currently bootstrapped on the host rather than the target, so maybe the changeover will make no difference?

I'm confused. I thought we copied the configuration from the target to the host as part of the bootstrapping process, but now I can't see how this is supposed to happen for HsBaseConfig.h. It looks like following the instructions in the building guide will result in failure if you try to cross-compile between machines with different word sizes, but I know I've done this in the past :-/ Ian, any idea how this is supposed to work? Anyway, to answer your question, using hsc2hs in System.Posix.Types will cause problems for bootstrapping GHC, yes, because we can't run hsc2hs on the target without GHC, but we can run configure. I suppose we could add a dependency on another Haskell compiler just to run hsc2hs, but that's a pain. Cheers, Simon

Malcolm Wallace

3:44 p.m.

Simon Marlow wrote:

...

I suppose we could add a dependency on another Haskell compiler just to run hsc2hs, but that's a pain.

I'm hoping that by the end of this summer, nhc98 will be able to compile the whole of ghc. :-) Also, and alternatively, the yhc chaps have mooted the idea of moving from nhc98's front end to ghc's, which might eventually give you a fully portable bytecode route to bootstrapping ghc on new machines. Pipe dreams for now though. Regards, Malcolm

Neil Mitchell

4:14 p.m.

...

I'm hoping that by the end of this summer, nhc98 will be able to compile the whole of ghc. :-) Also, and alternatively, the yhc chaps have mooted the idea of moving from nhc98's front end to ghc's, which might eventually give you a fully portable bytecode route to bootstrapping ghc on new machines.

We half thought about that, but a more direct goal is to be able to convert GHC Core to Yhc Core, then we can use either GHC's front end (via system) or Yhc's (natively). This would mean that we would be able to compile any library with GHC then use it with Yhc. This project will take about three days, once GHC has a non-broken Core library. Thanks Neil

Simon Marlow

13 Apr 13 Apr

8:29 a.m.

Neil Mitchell wrote:

...

Hi

...
I'm hoping that by the end of this summer, nhc98 will be able to compile the whole of ghc. :-) Also, and alternatively, the yhc chaps have mooted the idea of moving from nhc98's front end to ghc's, which might eventually give you a fully portable bytecode route to bootstrapping ghc on new machines.

We half thought about that, but a more direct goal is to be able to convert GHC Core to Yhc Core, then we can use either GHC's front end (via system) or Yhc's (natively). This would mean that we would be able to compile any library with GHC then use it with Yhc. This project will take about three days, once GHC has a non-broken Core library.

How do you plan to implement unboxed types? AFAIK, implementing unboxed types requires a typed intermediate language. Maybe you could get away with boxing all the unboxed types, but then Int would have an extra level of boxing. And the other big problem with implementing GHC core is all the primitives... Cheers, Simon

Neil Mitchell

9:29 a.m.

...

How do you plan to implement unboxed types? AFAIK, implementing unboxed types requires a typed intermediate language. Maybe you could get away with boxing all the unboxed types, but then Int would have an extra level of boxing.

Indeed, we intend to box everything. Plus there were compilers which did unboxing before having unboxed types - as the paper said, it wasn't as neat, but it was possible. I also have a design for a C backend where the Int can be packed into the pointer, which removes the boxes from all evaluated Ints.

...

And the other big problem with implementing GHC core is all the primitives...

The Yhc primitives aren't particularly nice, but we have a design in which they could be made much nicer, and also allow implementation of the GHC core primitives easily. This will probably be the larger chunk of work. Thanks Neil

Simon Marlow

1:48 p.m.

Neil Mitchell wrote:

...

Hi

...
How do you plan to implement unboxed types? AFAIK, implementing unboxed types requires a typed intermediate language. Maybe you could get away with boxing all the unboxed types, but then Int would have an extra level of boxing.

Indeed, we intend to box everything. Plus there were compilers which did unboxing before having unboxed types - as the paper said, it wasn't as neat, but it was possible.

Right, but the problem is that if you box all of GHC's unboxed types, you end up with an extra layer of boxing compared to an implementation that just boxes everything. ie. it'll be worse than YHC is currently, so you'll need extra trickery to get back to where YHC is now.

...

I also have a design for a C backend where the Int can be packed into the pointer, which removes the boxes from all evaluated Ints.

Presumably you lose one bit of precision though, so GHC's Int# type would be 31 bits. We did at one stage have a GHC->OCaml translator with a 31-bit Int#, so it might be possible, but I think there will be some assumptions in the libraries that break (eg. Int32 will need to be implemented using Int64#). Cheers, Simon

Neil Mitchell

1:53 p.m.

...

...
Indeed, we intend to box everything. Plus there were compilers which did unboxing before having unboxed types - as the paper said, it wasn't as neat, but it was possible.

Right, but the problem is that if you box all of GHC's unboxed types, you end up with an extra layer of boxing compared to an implementation that just boxes everything. ie. it'll be worse than YHC is currently, so you'll need extra trickery to get back to where YHC is now.

Possible, I'll have to think about this further. I was thinking along the lines of newtype Box a = Box !a then Int# = Box Int but I'm not sure if that will work or not. Anyway, its only a question of efficiency, and Yhc has a lot more things that will destroy efficiency than this!

...

Presumably you lose one bit of precision though, so GHC's Int# type would be 31 bits. We did at one stage have a GHC->OCaml translator with a 31-bit Int#, so it might be possible, but I think there will be some assumptions in the libraries that break (eg. Int32 will need to be implemented using Int64#).

We loose 2 bits, to leave room for enough tag bits. Fortunately this still fills the Haskell specification. We will have some method for implementing Int32, probably as a pointer once again. Thanks Neil

Claus Reinke

12 Apr 12 Apr

6:57 p.m.

...

I'm confused. I thought we copied the configuration from the target to the host as part of the bootstrapping process, but now I can't see how this is supposed to happen for HsBaseConfig.h. It looks like following the instructions in the building guide will result in failure if you try to cross-compile between machines with different word sizes, but I know I've done this in the past :-/ Ian, any idea how this is supposed to work?

Anyway, to answer your question, using hsc2hs in System.Posix.Types will cause problems for bootstrapping GHC, yes, because we can't run hsc2hs on the target without GHC, but we can run configure. I suppose we could add a dependency on another Haskell compiler just to run hsc2hs, but that's a pain.

how about a repository for platform-specific configuration files? that way you only need the first user on each platform to figure things out, either by installing extra tools or by modifying existing configuration files? btw, lots of things have changed since i last built ghc, but i thought it strange that configure used to rediscover platform-specific configuration data for each sub-project (each running its own configure, but not seeming all that specific in what to test for). claus

Simon Marlow

13 Apr 13 Apr

8:35 a.m.

Claus Reinke wrote:

...

...
I'm confused. I thought we copied the configuration from the target to the host as part of the bootstrapping process, but now I can't see how this is supposed to happen for HsBaseConfig.h. It looks like following the instructions in the building guide will result in failure if you try to cross-compile between machines with different word sizes, but I know I've done this in the past :-/ Ian, any idea how this is supposed to work?

Anyway, to answer your question, using hsc2hs in System.Posix.Types will cause problems for bootstrapping GHC, yes, because we can't run hsc2hs on the target without GHC, but we can run configure. I suppose we could add a dependency on another Haskell compiler just to run hsc2hs, but that's a pain.

how about a repository for platform-specific configuration files? that way you only need the first user on each platform to figure things out, either by installing extra tools or by modifying existing configuration files?

The case we're worried about is the first time you port to a new platform, because after that we have a working compiler so there's no problem. The instructions in the GHC building guide describe how to do this (http://hackage.haskell.org/trac/ghc/wiki/Building/Porting). It's not especially well supported by the build system, so the process is a bit fiddly, but we have to be careful to make sure it is at least possible to do it and not too tortuous. Cheers, Simon

Malcolm Wallace

12 Apr 12 Apr

7:49 p.m.

Simon Marlow writes:

...

...
Ah. I was about to checkin a replacement for System.Posix.Types (in base) that uses hsc2hs instead of autoconf.

Anyway, to answer your question, using hsc2hs in System.Posix.Types will cause problems for bootstrapping GHC, yes, because we can't run hsc2hs on the target without GHC, but we can run configure.

But it is only a problem for cross-compiling - yes? And no more of a problem than ghc already has? So, should I push my patch for building System.Posix.Types with nhc98 (i.e. without autoconf, with hsc2hs) or not? At the moment, the lack of System.Posix.Types is breaking the nightly builds of Cabal/nhc98. Regards, Malcolm

Ian Lynagh

9:39 p.m.

On Thu, Apr 12, 2007 at 08:49:03PM +0100, Malcolm Wallace wrote:

...

Simon Marlow writes:

...
...
Ah. I was about to checkin a replacement for System.Posix.Types (in base) that uses hsc2hs instead of autoconf.

Anyway, to answer your question, using hsc2hs in System.Posix.Types will cause problems for bootstrapping GHC, yes, because we can't run hsc2hs on the target without GHC, but we can run configure.

But it is only a problem for cross-compiling - yes?

Yes.

...

And no more of a problem than ghc already has?

No, with the configure method we can run configure on the target and copy the files back to the host. The instructions at http://hackage.haskell.org/trac/ghc/wiki/Building/Porting do so for includes/ghcautoconf.h includes/DerivedConstants.h includes/GHCConstants.h and look like they ought to for libraries/base/include/HsBaseConfig.h too. But we can't run hsc2hs on the target without having a Haskell compiler there. Thanks Ian

Malcolm Wallace

13 Apr 13 Apr

4:09 p.m.

I wrote:

...

So, should I push my patch for building System.Posix.Types with nhc98 (i.e. without autoconf, with hsc2hs)?

OK, I have pushed a revised patch, which should not alter the behaviour for ghc at all. I moved the invocation of hsc2hs into the NHC.* hierarchy, and just re-export that module from System.Posix.Types instead. Regards, Malcolm

Ian Lynagh

12 Apr 12 Apr

9:31 p.m.

On Thu, Apr 12, 2007 at 04:33:27PM +0100, Simon Marlow wrote:

...

I'm confused. I thought we copied the configuration from the target to the host as part of the bootstrapping process, but now I can't see how this is supposed to happen for HsBaseConfig.h. It looks like following the instructions in the building guide will result in failure if you try to cross-compile between machines with different word sizes, but I know I've done this in the past :-/ Ian, any idea how this is supposed to work?

I guess we've just been lucky. "#define HTYPE_INT Int32" is probably true everywhere we've tried in recent years, and probably covers most of the potentially troublesome cases. Thanks Ian

6663

Age (days ago)

6668

Last active (days ago)

List overview

Download

23 comments

8 participants

participants (8)

Bulat Ziganshin
Chris Kuklewicz
Claus Reinke
Gregory Wright
Ian Lynagh
Malcolm Wallace
Neil Mitchell
Simon Marlow