public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Nathan Sidwell <nathan@codesourcery.com>
To: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>,
	hubbard@ilm.com, jyost@ilm.com, kainz@ilm.com, bramsh@acm.org
Cc: Mark Mitchell <mark@codesourcery.com>, gcc@gcc.gnu.org
Subject: Re: GCC 3.0.3: Bugs to Fix
Date: Mon, 03 Dec 2001 01:57:00 -0000	[thread overview]
Message-ID: <3C0B4C55.D64E226A@codesourcery.com> (raw)
In-Reply-To: <200111302322.03466@enzo.bigblue.local>

Franz Sirl wrote:
> 
> On Thursday 29 November 2001 22:53, Mark Mitchell wrote:
> > Here are some bugs that it would be nice, although not imperative,
> > to fix before 3.0.3:
> 
> What about PR3993? Another KDE2 blocking bug...
Is there a reason that dlopen ("foo", RTLD_NOW | RTLD_GLOBAL)
is unacceptable?

The ABI was designed on the assumption that it is possible at link
or load time to collapse objects with the same name to a single address,
and thus use address comparisons to determine equality. Loading without
RTLD_GLOBAL break that.

Presumably you'll also observe that it's possible for the 'same function'
has two different addresses, one in the library and one not in the library.

[5.10] says 'Two pointers ... compare equal if and only if ... both point
to the same object or function ...' 
Ooh, that's not actually the same as
	'Two pointers compare unequal if and only if they point to different
objects or functions'
(but I always thought that was true, defect anyone?)

Anyhow, from the ABI spec point of view, you've fallen outside the ABI
by disjointing the namespace.  To make it work without RTLD_GLOBAL would
pessimize type comparisons because we'd have to compare strings rather than
pointers to strings.  What's worse is that it's the 'unequal to' comparison
that could not be optimized, and IMO, dynamic cast & catch have more
not-equal cases than equal cases.

If we HAD to make this work at ANY cost, then I'd change the ABI to secrete
a hash of the typename that could be compared in O(0), rather than O(length).
But see - that's an ABI change.

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

  parent reply	other threads:[~2001-12-03  9:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-22  0:08 Mark Mitchell
2001-11-22  0:47 ` Richard Henderson
2001-11-22  5:37   ` Mark Mitchell
2001-11-29 17:10     ` Mark Mitchell
2001-11-29 15:13   ` Richard Henderson
2001-11-22 16:00 ` Nathan Sidwell
2001-11-30  1:40   ` Nathan Sidwell
2001-11-23 16:49 ` Franz Sirl
2001-11-30 14:23   ` Franz Sirl
2001-12-03  1:57   ` Nathan Sidwell [this message]
2001-12-03  3:15     ` Andreas Schwab
2001-12-03  3:37       ` Nathan Sidwell
2001-12-03  9:27     ` Mark Mitchell
2001-12-03  9:40       ` Joe Buck
2001-12-03  9:46         ` Mark Mitchell
2001-12-03 12:04       ` Florian Kainz
2001-12-03 12:06         ` Mark Mitchell
2001-12-04  0:51         ` Alexandre Oliva
2001-12-04  0:49     ` Alexandre Oliva
2001-12-03  8:49   ` Mark Mitchell
2001-12-07 12:24     ` Franz Sirl
2001-11-29 13:58 ` Mark Mitchell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C0B4C55.D64E226A@codesourcery.com \
    --to=nathan@codesourcery.com \
    --cc=Franz.Sirl-kernel@lauterbach.com \
    --cc=bramsh@acm.org \
    --cc=gcc@gcc.gnu.org \
    --cc=hubbard@ilm.com \
    --cc=jyost@ilm.com \
    --cc=kainz@ilm.com \
    --cc=mark@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).