On Thu, 2009-06-25 at 22:40 +0200, Raphael Hertzog wrote:
> Hello,
>
> it is well known that C++ symbol mangling result in different symbol
> names from one architecture to the other. It means that libraries that
> want to provide symbol files have to maintain one symbol file for each
> architecture. To avoid this problem Modestas Vainius has written a patch
> that lets you encode in a specific way the small parts in the symbol name
> that vary between architecture.
>
> You can check the patch here:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=0001-Implementation-of-the-subst-tag.patch;att=1;bug=533916
>
> The symbol name in symbols files become templates that are used at build
> time to generate the correct symbol name. The part that are substituded
> are delimited by curly brackets like this:
> (subst)_ZN6Phonon11AudioOutput13volumeChangedE{qreal}@Base 4:4.2.0
>
> In this specific case, the symbol is considered to be
> _ZN6Phonon11AudioOutput13volumeChangedEf@Base on armel
> and _ZN6Phonon11AudioOutput13volumeChangedEd@Base on other arches
> because qreal is a float on armel and a double otherwise.
>
> Here are my questions for people that are more knowledgeable than me about
> C++ symbol name mangling:
>
> - how stable are those substitution over time? and is it reasonable
> to maintain a list of substitution in dpkg-dev for this purpose?
AFAIK the g++ name-mangling rules have been stable, modulo bugs, since
g++ 3.0.
> - it's probably impossible to have substitutions to cover all cases
> for C++ symbol mangling... do you believe that it is possible
> to have enough (stable) substitutions to cover most common cases?
>
> (in the current patch there is ssize_t, size_t, int64_t, uint64_t,
> qreal and vt=<size> for C++ virtual table offset)
[...]
The implementation of the substitution vt=<size> seems to be intended to
cover virtual function thunks, but I think it is wrong.
First, some background. In a class with multiple bases, all but one
base class instance must be offset from the address of the derived class
instance. If the derived class overrides a virtual function from one of
these bases, the compiler must generate a wrapper function, a "virtual
function thunk", which subtracts that offset from the "this" pointer
before calling the implementation. In the case of virtual inheritance,
a more complex adjustment is necessary.
The symbol names for virtual function thunks include a description of
the adjustment, taking the form:
"Th" <non-virtual-offset>
or "Tv" <non-virtual-offset> "_" <virtual-offset>
Since the <non-virtual-offset> depends on the sizes of base classes,
there is no simple relationship between its values on different
architectures. This may be true for the <virtual-offset> as well but
I'm not sure.
There's also a nasty possibility that on some architectures two
parameter types could be identical and so the second instance would be
represented by a back-reference ("S_" or "S" <number> "_"), whereas on
others they would be different and the second would be represented
independently.
Ben.
--
Ben Hutchings
It is impossible to make anything foolproof because fools are so ingenious.
Attachment:
signature.asc
Description: This is a digitally signed message part