Re: defining unique symbols (Herman Rubin)
27 Jul 1997 23:37:28 -0400

          From comp.compilers

Related articles
defining unique symbols (1997-07-13)
Re: defining unique symbols (1997-07-16)
Re: defining unique symbols (Jerry Leichter) (1997-07-16)
Re: defining unique symbols (Pieter Schoenmakers) (1997-07-16)
Re: defining unique symbols michael.ball@Sun.COM (MICHAEL BALL) (1997-07-22)
Re: defining unique symbols (1997-07-27)
| List of all articles for this month |

From: (Herman Rubin)
Newsgroups: comp.compilers
Date: 27 Jul 1997 23:37:28 -0400
Organization: Purdue University Statistics Department
References: 97-07-052 97-07-082 97-07-103
Keywords: linker

Jerry Leichter wrote:
>> If there are no non-inlined members, the you have to fall back on
>> having multiple vtable's. I don't know what these compilers do if no
>> module ever defines the first non-inlined member function - if it's
>> never called, that's certainly legal. I've seen error messages from
>> some C++ compilers that seem to indicate that they don't recover
>> gracefully in this situation.

MICHAEL BALL <michael.ball@Sun.COM> wrote:
>The usual algorithm is to use the first VIRTUAL non-inline member
>function. This must be defined or the program won't link.

>> I suspect C++ compilers are using the same algorithm for deciding who
>> defines the RTTI data structures. This can have nasty side-effects:

>You have to fall back on some other form of uniqueness for this.
>For example, on Solaris, within a single executable or non-shared
>library it is sufficient to make the name weak. In that case the
>linker will pick the first one encountered. It wastes some
>space, but that's usually minor. With shared objects it's more
>difficult, but you can use the linkers interposition rules to
>achieve the same effect. (Only with functions though, so you have
>to use functions as proxies to get at the data structures.) The
>current SunSoft compilers use this. The template instantiatian
>scheme provides another (expensive) solution

>We decided that this was all horrible enough that we would get
>our uniqueness by unique spellings and avoid all this mess for the
>next ABI. This reduces the question to one of wasted space, just
>as for vtables.

I can see problems with this. It is possible to want to have routines
from different libraries which have the same name; the program would
have to have a way to distinguish them, and at run time it would have
to have a way to pick which one it wants, but it is neither possible
nor desirable to change the name in the libraries. It might also be
desired to put in alternatives in the program or subroutines compiled
with it.

Another situation here is that of choosing which array to use for a
given purpose at run time.

One way around this is to use function pointers and array pointers,
with the "executive" part of the program setting these, and have the
function call in that manner. But there still has to be a way to load
items with the same name from different libraries, even if they are
aliased in the program to have different names.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (765)494-6054 FAX: (765)494-0558
[For once I agree with Herman, tree-structured naming in libraries would
make them a lot more useful and flexible. -John]


Post a followup to this message

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