Re: defining unique symbols

fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>OK, fine so far. Now the catch is that we would like to be able to
>compare two different type_ctor_infos by simplying comparing their
>addresses (rather than say doing a string comparison on their "name"
>fields). In order to do that, we need to ensure that there is exactly
>one definition of each type_ctor_info in the final executable. This
>is a bit difficult to do in the presence of separate compilation,
>because we want to be able to use the standard system linker. Oh, and
>I forgot to mention that our compiler generates C code.


I haven't seen a good solution to this problem without replacing the
1950's linkers of which everyone seems so enamoured. I have
considered the problem, and here is a partial solution...


In each .dll you can have a pointer to each of its required
type_ctor_info structures. This allows the .dll to find the required
type_ctor_info structure by simply loading its address (this requires
an extra indirection compared to simply loading the address when
needed).


You can have in the .exe a collection of all type_ctor_info
structures. As each .dll is loaded, and the _dllinit() routine is
run, it can check each of its type_ctor_info structures in that single
collection (by name). If one by the same name is found, then the
pointer maintained in the .dll should be replaced with the address
found in the collection. If one is not found, then it should be added
to the collection.


The result of the above is that there might be duplicate
type_ctor_info structures around, but only a single version will be
used at run-time. That will allow you to compare by address. You
will NOT be able to use a hard-coded address for a type_ctor_info
structure, you must always obtain the address by using the local
pointer (or by looking it up in the collection).


There are two "gotchas" with this technique. First, if different dll
files can use the same name for different classes, you have a conflict
and you can't do this type of thing at all.


Second, if you load .dll files dynamically, you must have some way of
temporarily adding type_ctor_info structures to the collection, and
some data which will prevent the dynamic .dll from being unloaded as
long as one is in use (which might come into play if you load two
dynamic .dll files). That means that your class constructors might
need to reference count the type_ctor_info structure.


Even redesigning a linker won't eliminate the problem with dynamic
.dll loading, so something like this is probably what you need.


Michael Lee Finney
--

Return to the comp.compilers page.
Search the comp.compilers archives again.