Re: GNU dlopen(3) differs from POSIX/IEEE

[Suprateeka R Hegde <hegdesmailbox@gmail.com>]

On 18-Jun-2016 11:02 AM, Carlos O'Donell wrote:
> 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.

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)
---

This made me think that GNU implementation also matches with other 
implementations -- that is lazy resolution happens at the time of the 
first 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,

Yes. I agree very much. But making some massive enterprise legacy 
application to become "well-defined" now is beyond tool chain writers.

The very use of --unresolved-symbol=ignore all for an executable link is 
bad in a way.

> 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.

This is going to be a "mode". Almost similar to BIND_NOW. But not 
default. Even if decided default, a non-default (lazy writable PLTs) 
mode still exists.

> 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.

Both are mutually exclusive. In my opinion, programs either want 
immediate binding or lazy binding. Not an arbitrary mix of both.

> However, because POSIX says nothing about when the lazy symbol
> resolution happens, or anything at all about it,

It indeed says something:
---
RTLD_LAZY

Relocations shall be performed at an implementation-defined time, 
ranging from the time of the dlopen() call until the first reference to 
a given symbol occurs
---

And then based on the ld(1) manpage, I thought GNU/Linux implementation 
uses the time of first call.

What is the harm if we go by the existing documentation and under the 
option -z lazy or RTLD_LAZY, make lazy resolution happen at the point of 
function call?

(BTW, the above is already in place currently and is working as expected)

And eventually change the semantics of RTLD_GLOBAL to match the 
description mentioned in the POSIX spec -- ...relocation processing of 
any other executable object file.

--
Supra