This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
-fno-weak, typeinfo, and AIX
- To: gcc at gcc dot gnu dot org, Jason Merrill <jason at cygnus dot com>
- Subject: -fno-weak, typeinfo, and AIX
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Thu, 25 Jan 2001 16:17:45 -0800
- Organization: CodeSourcery, LLC
The new ABI's C++ typeinfo implementation depends on having only one
copy of the type name string in the final executable. Then, typeinfo
equality is just equality of the address of this string.
Unfortunately, if you do not have weak symbols, you cannot pull this
off. For classes without a key function, you need to emit the
typeinfo information statically, in every .o, and then do a full
string comparison at run-time. (Alternatively, you could have
`collect2' look for undefined typeinfo symbols, and define them at
link time, but that wouldn't work across shared objects.)
So, on AIX, we need to:
- Emit typeinfo statically when there is no key function
- Modify the run-time library to do a string comparison, not an
address comparison, of the typeinfo strings.
Both are relatively easy tasks.
However, this also begs a usability question. On all targets, even
those that do support weak symbols, g++ provides a -fno-weak flag that
turns them off.
It's not clear to me why we provide this flag, since the weak symbols
approach works much more smoothly. I'm pretty sure that nobody uses
this flag, because things don't work well when you do use it!
Furthermore, in the new ABI, -fno-weak will break RTTI, since we only
want to slow down RTTI on the platforms where we really need to.
Therefore, I propose doing the following things, necessary to get AIX
support working reasonably well:
- Changing G++ to emit typeinfo statically if the target does
not support weak symbols.
- Modify the support runtime to do strcmp's on AIX.
- Remove -fno-weak, except in so far as to issue a message saying
it is no longer supported, and remove it from the documentation.
The last step is technically optional, but will reduce user confusion.
Thoughts?
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com