[m-rev.] for review: fix problems with --split-c-files

Zoltan Somogyi zs at cs.mu.OZ.AU
Thu Aug 8 15:37:43 AEST 2002


On 08-Aug-2002, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> Why not just qualify the names of the conflicting symbols with the module
> name?

That was the approach I started with.

One problem with it is that the straightforward way of implementing it
required adding the module name as a new argument to a very large number
of predicates; pretty much everything in llds_out, and many in other modules
too.

I then got around this by adding the module name to the globals in the I/O
state. This field had to be updated when the compiler started compiling
a new module, but that could done.

Then I discovered the problem that made the approach untenable, which is that
module qualifying the names of the conflicting symbols doesn't actually solve
the problem, because you get conflicts with different .c files GENERATED FROM
THE SAME MERCURY MODULE defining the same symbol.

The problem is that --split-c-files splits up the list of data structures,
but a single comp_gen_c_data item can now expand to multiple C global data
definitions. For example, --split-c-files puts the definitions of the
type_ctor_infos of ra_list/1 and ra_list_bintree/1 in bt_array.m in different
C source files, but both of those will include a pseudotypeinfo representing
ra_list_bintree(T), since both those type constructors have a function symbol
argument with that type. Since we construct the name of the C global containing
a pseudotypeinfo's representation from the value of the pseudotypeinfo, this
guarantees a name collision. The only way to avoid the name collision causing
a link failure is to make the globals involved static.

Zoltan.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the reviews mailing list