Re: Removing longjmp error handling from the dynamic loader

[Florian Weimer <fweimer at redhat dot com>]

* Carlos O'Donell:

>> One thing we have not considered much so far is what you call “free
>> lists”, and generally not doing any unrecoverable actions until we reach
>> the point of no return in dlopen (and eliminating the possiblity of
>> failures in dlclose, by avoiding calling malloc there).  For example, we
>> could store the temporary file descriptors in the exception context (by
>> a callout to libc.so.6) and make sure that they are closed when
>> unwinding.  We can avoid memory leaks for temporary allocations in much
>> the same way.
>> 
>> In a sense, we would provide a more approachable programming environment
>> for unwinding.
>
> OK, so lets expand on that a bit, if you went down this route what do
> the steps look like? If you enumerate them a bit more I think we'll
> all be able to comment on them first, and then agree that it's the
> right way forward.

I haven't read all of the loader code, but I think we need to manage at
least the following resources:

* The loader lock
* Temporary memory allocation (e.g. file name buffers)
* Persistant memory allocations related to the link map
* Other persistant memory allocations
* One file descriptor
* File mappings
* How new link maps are hooked into the loader state
* Updates to global loader state (various search paths)
* Maybe TLS data in the future (if we allocate it eagerly)

Ideally, there would be a precise point, clearly indicated in the source
code, at which which we know that dlopen cannot fail.  I tried to
identify this point in the existing sources, but it is entirely unclear
where it should be.

Conceptually, I think we all agree is that it has to come before we call
the ELF constructors.

After the point of no return, we cannot do anything that might
potentially fail in a non-critical fashion, such as allocating memory.
For example, in the current code, we appear to call malloc in
add_to_global, when adding the new objects to the global scope.  We
would have to perform this allocation beforehand (and make sure that we
do not need more memory afterwards because some other thread made
further changes).

So overall, I think the longjmp vs no longjmp discussion may be a
distraction, and the harder problems lie elsewhere.

Please also consider Rich Felker's comments regarding lazy binding
failures in IFUNC resolvers; for those we would have to use longjmp
anyway if we want to keep them as non-fatal because the IFUNC resolver
may not have unwinding information.

Thanks,
Florian