[m-dev.] for review: cleanup of type_ctor_infos, part 2

[Fergus Henderson]

On 25-Feb-2000, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> Index: compiler/rtti.m
...
> +	% Create a C variable name for a record of the locations of the
> +	% typeinfos for a functor's existentially typed arguments.
> +
> +:- pred rtti__make_exist_locns_name(rtti_type_id::in, int::in,
> +	string::out) is det.

What does the int argument to this predicate represent?

> +	% Create a C variable name for a summary record of a functor's
> +	% existentially typed arguments.
> +
> +:- pred rtti__make_exist_info_name(rtti_type_id::in, int::in,
> +	string::out) is det.
...
> +	% Create a C variable name for the array listing the names
> +	% of the fields of a function symbol.
> +
> +:- pred rtti__make_field_names_name(rtti_type_id::in, int::in,
> +	string::out) is det.
...
> +	% Create a C variable name for an enum functor descriptor.
> +
> +:- pred rtti__make_enum_functor_desc_name(rtti_type_id::in, int::in,
> +	string::out) is det.
...
> +	% Create a C variable name for a du functor descriptor.
> +
> +:- pred rtti__make_du_functor_desc_name(rtti_type_id::in, int::in,
> +	string::out) is det.
...
> +	% Create C variable a name for a list of du functor descriptors
> +	% sharing a primary tag ordered on value.
> +
> +:- pred rtti__make_du_stag_ordered_table_name(rtti_type_id::in,
> +	int::in, string::out) is det.
...
> +	% Create a C variable name for a du_ptag_layout
> +
> +:- pred rtti__make_du_ptag_layout_name(rtti_type_id::in, int::in,
> +	string::out) is det.

Likewise for all these predicates.

> Index: compiler/rtti_out.m
> ===================================================================
> RCS file: rtti_out.m
> diff -N rtti_out.m
...
> +output_rtti_data_defn(type_ctor_info(RttiTypeId, Unify, Index, Compare,
> +		CtorRep, Solver, Init, Version, NumFunctors,
> +		FunctorsInfo, LayoutInfo, MaybeHashCons,
> +		Prettyprinter), DeclSet0, DeclSet) -->
...
> +	(
> +		{ FunctorsInfo = enum_functors(EnumFunctorsInfo) },
> +		io__write_string("{ (Integer) "),
> +		output_rtti_addr(RttiTypeId, EnumFunctorsInfo),
> +		io__write_string(" }")
> +	;
> +		{ FunctorsInfo = notag_functors(NotagFunctorsInfo) },
> +		io__write_string("{ (Integer) &"),
> +		output_rtti_addr(RttiTypeId, NotagFunctorsInfo),
> +		io__write_string(" }")
> +	;
> +		{ FunctorsInfo = du_functors(DuFunctorsInfo) },
> +		io__write_string("{ (Integer) "),
> +		output_rtti_addr(RttiTypeId, DuFunctorsInfo),
> +		io__write_string(" }")
> +	;
> +		{ FunctorsInfo = no_functors },
> +		io__write_string("{ 0 }")
> +	),

Hmm... here you are casting pointers to integers,
and you're using the resulting expressions in static initializers, right?
If so, I'm not sure that is guaranteed to work.
There are definitely problems doing that for code addresses
on some systems, and I think there might be similar problems
with doing it for data addresses too.

Hmm, checking the log messages for llds.m, it seems that my
recollection was correct:

 | revision 1.176
 | date: 1996/04/06 19:00:22;  author: fjh;  state: Exp;  lines: +26 -9
 | Estimated hours taken: 1
 |         (plus lots of time debugging the problem via email)
 | 
 | Fix a second occurrence of the problem with casts in the initializers
 | of static constants causing gcc to generate non-position-independent code.
 | This prevented the use of gcc on AIX RS/6000 systems, and was also
 | preventing us from creating genuinely shared shared libraries on Solaris.
 | 
 | compiler/llds.m:
 |         Emit static constants as `const Word * mercury_const_n [] = { ... }'
 |         rather than `const Word mercury_const_n [] = { ... }' not just
 |         in the case when the constant contains code addresses, but also
 |         when it contains data addresses, including addresses of other
 |         static constants and/or string literals.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------