Re: trying to get a registerised alpha build

On Fri, 2006-03-31 at 11:43 +0100, Simon Marlow wrote:
> Duncan Coutts wrote:
> 
> > What would you recommend is the bat way for us to verify that each bit
> > of the registerised build is working? If we turn everything on including
> > the mangler and it breaks where do we start debugging?
> 
> I usually do this in one big step.

Right 'o. :-)

> Regarding debugging, I just wrote this wiki page:
> 
>    http://hackage.haskell.org/trac/ghc/wiki/DebuggingGhcCrashes
> 
> That should tell you everything you need to know, please feel free to 
> expand it as you discover things.

That's fantastic, thanks.

> > Is it possible to build without tailcalls (ie using the
> > mini-interpreter) but using the stg->machine register mappings?
> 
> Certainly.  I think if you use -optc-DUSE_MINIINTERPRETER and 
> -fno-asm-mangling everywhere, that should get you registers but no 
> mangling or tail calls.

Unfortunately this doesn't quite work because the TABLES_NEXT_TO_CODE
ends up inconsistent. I'm not quite sure why that happens to be honest.

Our clue is that the sanity check in initStorage barfs:
  ASSERT(LOOKS_LIKE_CLOSURE_PTR(&stg_dummy_ret_closure));

By looking at this in gdb (thanks again for the ghc gdb guide!) we found
that this is because this closure was generated assuming
TABLES_NEXT_TO_CODE to be true but of course since we're using
-optc-DUSE_MINIINTERPRETER then the rts .c code is getting compiled
with !TABLES_NEXT_TO_CODE which changes the definition of
LOOKS_LIKE_CLOSURE_PTR.

#ifdef TABLES_NEXT_TO_CODE
#define INFO_PTR_TO_STRUCT(info) ((StgInfoTable *)(info) - 1)
...
#else
#define INFO_PTR_TO_STRUCT(info) ((StgInfoTable *)info)
...
#end

So the .c code is using the latter definition which makes our info entry
look like this:

<ferdy> (gdb) p *(StgInfoTable *)0x121358008
<ferdy> $7 = {entry = 0, layout = {payload = {ptrs = 10, nptrs = 0},
bitmap = 10, large_bitmap = 0xa, selector_offset = 10}, type =
556545176,  srt_bitmap = 1}

which is obviously bogus. The type field should never be that big. If
however we use the definition we'd have use if TABLES_NEXT_TO_CODE were
true then we get:

<dcoutts> p *(((StgInfoTable *)0x121358008) - 1)
<ferdy> $8 = {entry = 0x2164657265746e, layout = {payload = {ptrs = 1,
nptrs = 1}, bitmap = 4294967297, large_bitmap = 0x100000001,
selector_offset = 4294967297}, type = 54, srt_bitmap = 0}

which looks fine. So we conclude that the stg_dummy_ret_closure is
getting built with the wrong tables next to code setting.

rts/StgMiscClosures.cmm:CLOSURE(stg_dummy_ret_closure,stg_dummy_ret);


So what we're wondering is what might have caused this inconsistency and
how might we fix it?

Just for reference we're now using this mk/build.mk:

GhcUnregisterised = NO
GhcLibWays =
GhcLibHcOpts :=
GhcStage1HcOpts = 
GhcStage2HcOpts = -DDEBUG -debug
GhcBootLibs = YES
SplitObjs = NO
SRC_HC_OPTS = -O0 -H32m -fno-asm-mangling -optc-DUSE_MINIINTERPRETER -optc-g
SRC_CC_OPTS = -DUSE_MINIINTERPRETER
GhcWithInterpreter = NO

(The GhcBootLibs = YES is a hack to make it a bit quicker to build, it
needs a little manual intervention to work from a top level make, ie
disabling building hslibs)

Duncan