[Haskell-cafe] hsb2hs preprocessor looking for a maintainer

Sergei Trofimovich slyich at gmail.com
Thu Aug 5 13:23:53 EDT 2010


Hi Max,

> > I believe the main reason why ghci isn't available on all platforms is
> > the dynamic linker.  I don't think it would be easy (or even feasible)
> > to switch to something like 'ld', though.
Some serious problems can be solve this way. This one is a nice example:
    http://hackage.haskell.org/trac/ghc/ticket/2615

I like the way GHC abstracted from foreign function call interface via libffi.
It works on everything where i tried GHC. Would be nice to have exactly the
same thing for ELF(and more) loader.

> AFAIK the current linker is meant to support Mach O, ELF and COFF,
> which should cover almost every platform GHC is able to run on. Now,
> it's not ideal that GHC maintains its own dynamic linker
> implementation, but if someone has discovered a bugs with it (or any
> other bug preventing TH from working) I'm sure GHC HQ would be
> interested in knowing.

Unfortunately, GHC itself not just 'dlopen's shared objects. It loads them
by pieces manually setting up relocations (see makeSymbolExtra by link below).

Each operating system on certaion $ARCH defines it's own ELF spec, which consists of two parts:
    1. common part. platform agnostic (byte sex, byte width, symbol string table,
       section flags, dynamic section attributes and etc.)
    2. platform dependant. certain section types, such as TOC sections (ppc64),
       are implemented to solve some certain architecture constraints. You cannot
       program them "in advance".
           $ grep PPC64 /usr/include/elf.h
       will show way more fun things to be implemented for perfect .so support.

The best thing to make sure is to look at the real support for ELF in ghci:

Please, look at file ghc/rtc/Linker.c and function do_Elf_Rela_relocations()
    http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=headblob;f=/rts/Linker.c

Conclusion: having ELF aware system is not enough to have ghci support in any form.

Practically, current gentoo supports ghci on:
    i386, amd64, ppc32, sparc(i'm unsure)
and does not support it on:
    alpha, ia64, ppc64

Ideally, GHC (and haddock as a result) should support 'ghci'less template-haskell support
at least on platforms w/o ghci.

Or alternatively haddock could be buildable on 'ghci'less GHC.
It could ignore template-haskell statements (anyway you will not be able to build
'TH'ful source on such platform)

-- 

  Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20100805/272dd269/signature.bin


More information about the Haskell-Cafe mailing list