[m-dev.] Re: diff: Runtime support for stack_layouts

[Tyson Richard DOWD]

Fergus Henderson wrote:
> Zoltan Somogyi <zs at cs.mu.oz.au> writes:
> 
> > [Tyson writes:]
> > > +#ifdef MR_USE_STACK_LAYOUTS
> > > +	/* 
> > > +	** The succip will be set to the address stored in the
> > > +	** layout info. For some reason, this is different to
> > > +	** the address passed to insert_entry
> > > +	*/
> > > +	addr = entry_layout_info[0];
> > > +#endif /* MR_USE_STACK_LAYOUTS */
> >
> >The comment is weird. I don't see any setting of succip, and I don't
> >see why the two definitions of addr should be different. This latter
> >matter must be resolved before we rely on layout tables.

Ooops, braino. "succip" in the comment should be "entry address".  

> 
> This is (I'll bet) due to the following problem with the DEC Alpha
> implementation of shared libraries.  This is the same problem that
> sometimes breaks Mercury's profiling if you use shared libraries on
> a DEC Alpha system.
> 
> The problem is that (a) the dynamic linker seems to resolve addresses lazily
> and (b) taking the address of a label in a shared library does not
> cause the dynamic linker to resolve the address -- at least not if
> the program is compiled with gcc.  It seems to work OK if the program
> is compiled with cc.

No, I don't think this is it, although I may be affected by this bug
in future anyway (I haven't tried dynamic linking yet).

The entry address comes from 
	init_label(some_label);

#define init_label(label)     make_label(stringify(label), &&label, label)

#define make_label(n, a, l)     make_entry(n, a, l)

#define make_entry(n, a, l)     insert_entry(n, a, MR_STACK_LAYOUT(l))


So in the end the second argument is "&&label". 

The stack layout contains:

        ENTRY(mercury__bag__intersect_2_4_0_i11)

#define ENTRY(label)        (&label)

So this is "&label".

I suspect this is the actual cause of my problems -- any succip I am
examining at runtime has the value &label, not &&label.

It seems that the label table indexes labels using &&label, which is
fine if you don't want to look up labels at runtime, but otherwise
probably pretty useless.

-- 
       Tyson Dowd           # To fix this, edit BLAH\BlahKey\Blah\Whatever 
                            # in the registry.
     trd at cs.mu.oz.au        # *WARNING* Editing the registry can DESTROY
http://www.cs.mu.oz.au/~trd # your machine forever. Do not do it.