This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [cxx-abi-dev] comparing type_infos (was Re: Patch forthrow/catch problems)
- To: Jakub Jelinek <jakub at redhat dot com>, Jason Merrill <jason_merrill at redhat dot com>
- Subject: Re: [cxx-abi-dev] comparing type_infos (was Re: Patch forthrow/catch problems)
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Tue, 14 Aug 2001 09:07:08 -0700
- cc: Richard Henderson <rth at redhat dot com>, David Lampell <david dot lampell at smarts dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "cxx-abi-dev at codesourcery dot com" <cxx-abi-dev at codesourcery dot com>
--On Tuesday, August 14, 2001 11:05:31 AM -0400 Jakub Jelinek
<jakub@redhat.com> wrote:
> On Tue, Aug 14, 2001 at 03:42:46PM +0100, Jason Merrill wrote:
>> >>>>> "Jason" == Jason Merrill <jason_merrill@redhat.com> writes:
>>
>> > I believe that this is a case of obsolete wording;
Maybe -- but it is what it says, and it is what people have implemented.
I know that there are C++ compilers out there with runtimes that do
pointer comparisons now...
Anyhow, there are two issues, both important:
- What happens with RTLD_LOCAL?
- How can we reduce startup cost?
They're somewhat different, even if they might have a related solution.
My opinion is that RTLD_LOCAL is not something we should even try to
get right. It's way too hard.
Startup cost happens once per program, except for any excess memory
used that hangs around. So, for a long-running application (anything
graphical definitely qualifies) this isn't *too* important, and there
are techniques (caching, prelinking) that can get around the problem.
On the other hand, there's no way I know of to recover the time you
lose by comparing type-infos slowly, and there really are programs
where that is the inner loop.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com