public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@redhat.com>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: 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: <69611e20-ed32-2133-274c-a30485e70f23@redhat.com> (raw)
In-Reply-To: <877fd5dr38.fsf@mid.deneb.enyo.de>

On 07/01/2016 04:46 PM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>>> ld(1) on a GNU/Linux machine says:
>>> ---
>>> -z lazy
>>>
>>> When generating an executable or shared library, mark it to tell the
>>> dynamic linker to defer function call resolution to the point when
>>> the function is called (lazy binding)
>>> ---
>>
>> Note that those man page is part of the linux man pages project and
>> are not canonical documentation for the glibc project.
> 
> This particular ld manual page seems to be derived from the
> ld/binutils Info documentation, which promises the same behavior.

The binutils manual should not dictate glibc behaviour.

Patch sent to binutils:
https://sourceware.org/ml/binutils/2016-07/msg00104.html
 
> I am not sure what the exact semantics of lazy binding should be.

The semantics of lazy binding are purposely vague to avoid constraining
the implementation. The reference to the symbol will be resolved at 
some point between load and call.

Do we need stricter semantics? Do the stricter semantics give us something
in return for the constraints we place on the implementation?

> With IFUNCs, lazy binding is observable, and we know from Fedora's
> BIND_NOW experiment that some applications assume that undefined
> functions which are never called do not cause any trouble whatsoever.
 
The IFUNC observes lazy binding only indirectly in that the resolver
is called one or more times depending on (a) number of object references
to the resolver and (b) number of threads concurrently updating GOT/PLT
entries and calling the ifunc resolver.

If there are relevant issues from Fedora's BIND_NOW testing that relate
to gnu-gabi, then we should raise them in a new thread.

-- 
Cheers,
Carlos.

  reply	other threads:[~2016-07-08  4:33 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
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             ` Carlos O'Donell [this message]
2016-01-01  0:00             ` Szabolcs Nagy
2016-01-01  0:00               ` Florian Weimer

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=69611e20-ed32-2133-274c-a30485e70f23@redhat.com \
    --to=carlos@redhat.com \
    --cc=fw@deneb.enyo.de \
    --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).