[m-dev.] for review: layouts without static code addresses

Fergus Henderson fjh at cs.mu.OZ.AU
Tue Nov 10 23:43:29 AEDT 1998


On 10-Nov-1998, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> Make stack layout structures work in grades that do not have static code
> addresses.
...
> runtime/mercury_goto.h:
> 	Fix a long-standing bug: init_local should treat its argument
> 	as an entry label, not as an internal label.

For clarity, I suggest

	s/an entry label/a procedure entry label/
                           ^^^^^^^^^

since the original bug was caused by confusion between things
being local to a procedure vs local to a module.

> +++ llds.m	1998/11/10 11:19:12
> @@ -648,8 +648,11 @@
>  	;	base_typeclass_info(class_id, string)
>  			% class name & class arity, names and arities of the
>  			% types
> +	;	proc_layout(label)
> +			% layout structure for the procedure of the given entry
> +			% label

Hmm, how about

s/procedure of the given entry label/procedure with the given entry label/
            ^^                                 ^^^^

?

> +	--->	local(proc_label, int)	% not entry; internal to a procedure
> +	;	c_local(proc_label)	% entry; internal to a C module
> +	;	local(proc_label)	% entry; internal to a Mercury module
> +	;	exported(proc_label).	% entry; exported from a Mercury module

I suggest s/entry/proc entry/g

> +:- pred label_is_entry(label::in, bool::out) is det.
> +
> +label_is_entry(local(_, _), no).
> +label_is_entry(c_local(_), yes).
> +label_is_entry(local(_), yes).
> +label_is_entry(exported(_), yes).

I suggest s/label_is_entry/label_is_proc_entry/g

> Index: library/benchmarking.m
...
>  BEGIN_MODULE(benchmark_nondet_module)
> +	MR_INIT_PROC_LAYOUT_ADDR(mercury__benchmarking__benchmark_nondet_5_0);
>  	init_entry_sl(mercury__benchmarking__benchmark_nondet_5_0);
>  	init_label_sl(mercury__benchmarking__benchmark_nondet_5_0_i1);
>  	init_label_sl(mercury__benchmarking__benchmark_nondet_5_0_i2);

The call to MR_INIT_PROC_LAYOUT_ADDR should come *after* the call
to init_entry_sl for that label, otherwise the proc layout field
will be initialized to an uninitialized value.

Same comment applies to all your other changes to library/*.m
and to your changes to llds_out.m.

> - --- mercury_stack_layout.h	1998/11/05 03:53:42	1.12
> +++ mercury_stack_layout.h	1998/11/10 01:01:20
> @@ -332,14 +332,34 @@
>  ** For the procedure identification, we always use the same module name
>  ** for the defining and declaring modules, since procedures whose code
>  ** is hand-written as C modules cannot be inlined in other Mercury modules.
> +**
> +** Due to the possibility that code addresses are not static, any use of
> +** the MR_MAKE_PROC_LAYOUT macro has to be accompanied by a call to the
> +** MR_INIT_PROC_LAYOUT_ADDR macro in the initialization code of the C module
> +** that defines the entry. (The cast in the body of MR_INIT_PROC_LAYOUT_ADDR
> +** is needed because compiler-generated layout structures have their own
> +** compiler-generated type.)

BTW, why do they have their own compiler-generated type?

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh>  |   but source code lives forever"
PGP: finger fjh at 128.250.37.3        |     -- leaked Microsoft memo.



More information about the developers mailing list