public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@redhat.com>
To: hegdesmailbox@gmail.com, gnu-gabi@sourceware.org
Subject: Re: GNU dlopen(3) differs from POSIX/IEEE
Date: Fri, 01 Jan 2016 00:00:00 -0000	[thread overview]
Message-ID: <42a86c64-a042-0c0d-9601-49729816c825@redhat.com> (raw)
In-Reply-To: <763cd6f7-e33d-8d14-c0ba-f4e5797ddfa6@gmail.com>

On 06/18/2016 12:11 AM, Suprateeka R Hegde wrote:
> All I am saying is, dlopen(3) with RTLD_GLOBAL also should bring in
> foo at runtime to be compliant with POSIX.

I disagree. Nothing in POSIX says that needs to be done. The
key failure in your reasoning is that you have assumed lazy
symbol resolution must happen at the point of the first function
call.

You have read "shall be made available for relocation" and
then used implementation knowledge to decide that _today_ those
relocations have a happens-after relationship with dlopen in your
program. But because lazy symbol resolution is not an observable
event for a well-defined program, and no guarantees are made, 
you can't make a happens-after relationship, and can't expect
'foo' to resolve to the loaded 'foo' that came into the global
scope with dlopen.

Perhaps in the future you want a mode where all lazy symbol
resolution is done before the first dlopen runs. Say we want to
do this to relocate the whole PLT and mark it read-only for
safety hardening.

If you were to _require_ lazy resolution to happen at the point
of the function call, which is what you're assuming here, then
it would prevent the above implementation from being conforming.
However, because POSIX says nothing about when the lazy symbol
resolution happens, or anything at all about it, your argument
is invalid.

What you observe on other implementations is a detail of the
implementation and a non-portable one.

-- 
Cheers,
Carlos.

  reply	other threads:[~2016-06-18  5:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-01  0:00 Suprateeka R Hegde
2016-01-01  0:00 ` Carlos O'Donell
2016-01-01  0:00   ` Suprateeka R Hegde
2016-01-01  0:00     ` Carlos O'Donell [this message]
2016-01-01  0:00       ` Suprateeka R Hegde
2016-01-01  0:00         ` Carlos O'Donell
2016-01-01  0:00           ` Suprateeka R Hegde
2016-01-01  0:00             ` Carlos O'Donell
2016-01-01  0:00           ` Florian Weimer
2016-01-01  0:00             ` Szabolcs Nagy
2016-01-01  0:00               ` Florian Weimer
2016-01-01  0:00             ` Carlos O'Donell

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=42a86c64-a042-0c0d-9601-49729816c825@redhat.com \
    --to=carlos@redhat.com \
    --cc=gnu-gabi@sourceware.org \
    --cc=hegdesmailbox@gmail.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).