[PATCH] [BZ#15903] INITFIRST flag does not change fini order (ld.so)
Guillaume Berard
berardgui@gmail.com
Thu Sep 19 20:06:00 GMT 2013
I don't fully understand the second part of the comment neither, to
me, the init order
should be already fine, so the reverse order should be good too... I
was just curious
about the comments above.
Is there a way to add unit tests to avoid regressions for the future?
On Thu, Sep 19, 2013 at 1:05 PM, Ondřej Bílka <neleai@seznam.cz> wrote:
> On Thu, Sep 19, 2013 at 10:48:18AM +0200, Guillaume Berard wrote:
>> I dig a bit in the code to find a clean solution, and I found this comment:
>>
>> /* Lots of fun ahead. We have to call the destructors for all still
>> loaded objects, in all namespaces. The problem is that the ELF
>> specification now demands that dependencies between the modules
>> are taken into account. I.e., the destructor for a module is
>> called before the ones for any of its dependencies.
>>
>> To make things more complicated, we cannot simply use the reverse
>> order of the constructors. Since the user might have loaded objects
>> using `dlopen' there are possibly several other modules with its
>> dependencies to be taken into account. Therefore we have to start
>> determining the order of the modules once again from the beginning. */
>>
>> So it seems that ELF specifications are not really working with the
>> initfirst specifications...
>> Just by curiosity, does anyone knows where I can find up-to-date ELF
>> specifications?
>> It could be a help to decide the behavior to adapt here.
>>
>
> I am not sure that I understand what is a problem. Is that some objects
> cannot be unloaded?
> If so then we could just do one pass to determine list of objects that
> need to be unloaded and then sort them in reverse init order and call
> destructors.
> Or with dynamic dependencies should we also load order in which they are
> loaded?
More information about the Libc-alpha
mailing list