B-5 Vtable heuristic
Jim Dehnert
dehnert at baalbek.engr.sgi.com
Wed Jul 21 23:04:05 UTC 1999
Let me try to summarize this, to see if I understand the issues and
status correctly. Please correct my misunderstandings, or clarify and
elaborate as needed.
1) Because there are no reliable heuristics for avoiding duplicate
vtable emission, there is concensus that we need a mechanism that allows
us to emit duplicates and remove them at link time. Further, there is
concensus that we will use a COMDAT-like mechanism, detecting and
removing duplicate data at section granularity.
This leaves several open questions:
A. The precise specification of the COMDAT representation and
semantics (must be resolved and submitted to psABI).
B. The name of the vtable (must be resolved, but may be handled
separately as part of F-1 mangling).
C. Using COMDAT sections will increase the section count,
perhaps dramatically, and may require a mechanism to avoid the
current 16-bit limit on section indices. (This should be
resolved, but is not obviously as urgent. However, since it
will require a psABI change and linker support, solving it
consistently earlier is better than later.)
2) Even with COMDAT support, in order to minimize relocatable object
file sizes, and minimize the (1C) issue above, it remains desirable to
implement heuristics to avoid as many duplicates as possible.
The traditional heuristic is to emit the vtable in the same object as
the definition of the first non-inline, non-pure-virtual member
function of the class -- called the key member function -- or, if no
such, always emit it. This fails if the key member function changes,
namely by declaring it inline in the file where it is defined but not
elsewhere. However, this behavior violates the Standard.
My intuition is that the member functions of most classes are defined
in one or a small number of files, suggesting a modification of this
heuristic: Always emit the vtable in a file defining any non-inline,
non-pure-virtual member function (or in any file where there are no
such member functions defined for the class). This will emit it in
more places, but it might not be much worse in practice, and should
be absolutely safe. If the original motivation for the stricter
traditional heuristic was that there was no COMDAT to take care of
residual duplicates, perhaps this is good enough once we have COMDAT?
Note that avoiding similar problems in programs linked from objects
produced by different compilers requires that the compilers all use
the same heuristic, so either agreement on heuristic or an ABI
compilation mode which always emits is required.
Outstanding issue:
D. What heuristic do we adopt?
3) Emission of out-of-line copies of inline routines is a related
issue. They could be emitted in the same file(s) as the Vtable (for
polymorphic classes). In fact, if we wanted to take advantage of the
language requirement that inline declarations be consistent, they could
all go in the same section(s). Has this been discussed?
Questions:
E. Where do we emit inline routines (G-3)?
F. Do we put multiple routines in the same COMDAT section?
- Jim Dehnert dehnert at sgi.com
(650)933-4272
More information about the cxx-abi-dev
mailing list