This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Mistake in C++ ABI substitution rules?
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Stan Shebs <shebs at apple dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Cc: cxx-abi-dev at codesourcery dot com
- Date: Wed, 20 Feb 2002 06:42:28 -0800
- Subject: Re: Mistake in C++ ABI substitution rules?
- References: <3C72D4BA.77E7125F@apple.com>
Stan --
I've forwarded your mail to the C++ ABI mailing list:
cxx-abi-dev@codesourcery.com
--On Tuesday, February 19, 2002 02:42:02 PM -0800 Stan Shebs
<shebs@apple.com> wrote:
> One of our tasks in migrating Darwin / Mac OS X to use GCC 3.x is
> to provide a way to load I/O drivers written in C++ and compiled
> with GCC 2.95. (Yeah yeah, bad idea, but the deed is done, and
> alternative is to compile the kernel's I/O subsystem with 2.95
> forever, I'll work hard to avoid that fate.)
>
> Anyway, to translate the symbols we have a homemade 2.95 compat
> demangler (written using a spec I handed to the kernel hacker,
> poor guy) feeding into a remangler written using the spec at
> http://www.codesourcery.com/cxx-abi/abi.html#mangling. So far
> so good, we have something that actually does the right thing
> most of the time. However, there is a troublesome point in the
> substitution rules for the new C++ ABI, where it says
>
> "Logically, the substitutable components of a mangled name are
> considered left-to-right, components before the composite structure
> of which they are a part. If a component has been encountered
> before, it is substituted as described below. This decision is
> independent of whether its components have been substituted,
> so an implementation MAY OPTIMIZE by considering large structures
> for substitution before their components. If a component has not
> been encountered before, its mangling is identified, and it is
> added to a dictionary of substitution candidates. No entity is
> added to the dictionary twice." (emphasis mine)
I think that "may" should be "must".
Thoughts?
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com