[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 06/20/2016 10:19 AM, Suprateeka R Hegde wrote:
>>> 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.
>>
>> That is not an assumption that developers should be making.
> 
> Not as a developer. I usually read manpages as an end user. As a
> developer I can clearly see whats happening currently. And whats
> happening currently matches the description in the manoage too. They
> are in sync now -- that is resolution at the time of first function
> call.

I have submitted a patch to correct this. First draft has been approved,
and a second draft with clarifications for STT_GNU_IFUNC has been
submitted.

> All I am proposing is to make the dlopen(3) RTLD_GLOBAL semantics to
> match that of POSIX/IEEE description.
 
They already match.

GNU dlopen(3) via RTLD_GLOBAL makes symbols available for relocation
processing.

POSIX/IEEE's RTLD_LAZY is the model for the executables own lazy symbol
resolution and there the text of the standard says:
"at an implementation-defined time, ranging from the time of the dlopen()
call until the first reference to a given symbol occurs."

In the case of GNU dlopen(3) I do not wish to constrain the implementation
by saying exactly when the lazy resolution happens, and I see no strong
justification to make it "at the time of the call" and to enforce global
symbol searches from dlopen'd RTLD_GLOBAL symbols.

>> That is not a good reason to be overly prescriptive in the standard.
> 
> I think we have a very minor difference of opinion in the whole
> discussion. To re-iterate, I am not proposing to restrict binding
> behaviors either to be NOW or be LAZY. We can add anything in between
> to optimize or secure. We can add them under an option as I said and
> make it default too.

The existing implementation is conforming as far as I can see.

What you want is for the implementation-defined time to be documented
as "at the time of the call" and therefore to be required to consider
the symbols brought in by the dlopen via RTLD_GLOBAL.

I do not feel that you have provided enough technical justification
for this requirement. We don't know how this might impact the existing
GNU userspace for the sake of a singular use case you present here.

I could be convinced otherwise, but I am not yet convinced that the
existing semantics should be changed.
 
-- 
Cheers,
Carlos.