Re: Removing longjmp error handling from the dynamic loader

[Carlos O'Donell <carlos@redhat.com>]

On 3/11/19 2:39 PM, Florian Weimer wrote:
>> So to be clear, you're proposing:
>>
>> "Method 3: Explicit this"
>>
>> Which you argue has highest value, with lowest cost.
> 
> Yes, and it also has the best tool support, I think.
> 
> We could use the knowledge gained by the conversion to fix bugs, but I
> think it will bit-rot over time, as people add more
> architecture-specific code and support more features in the dynamic
> linker.
> 
>> While I've been arguing for "Method 2: C exceptions" which you believe
>> has too much cost given the value, since we'd have to:
>> - move the unwinder to libc
>> - switch to some C++ subset
> 
> This sounds tempting as well, but I'm not sure if it's the right place
> to start with using C++ in glibc.

I can accept that :-)
 
> 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.

-- 
Cheers,
Carlos.