Re: Removing longjmp error handling from the dynamic loader

[Florian Weimer <fweimer@redhat.com>]

* Zack Weinberg:

> On Mon, Mar 11, 2019 at 12:13 PM Carlos O'Donell <carlos@redhat.com> wrote:
>> On 3/11/19 11:29 AM, Florian Weimer wrote:
>> > It requires moving the unwinder implementation from libgcc_s to libc,
>> > though.  The last time we discussed this (related to unwinder
>> > performance issues and the dl_iterate_phdr interface), this idea was not
>> > well-received.
>>
>> It might still be the best technical choice.
>> I do not think we should discard this idea so easily.
>> Why wouldn't we pursue this option?
>
> I haven't thought about this much, but I don't like the idea of
> increasing the set of functions potentially executed during symbol
> resolution to the tune of the entire unwinder, because of the unusual
> constraints on code executed in that context (e.g. must not take
> locks, must protect itself from cancellation, must not touch the
> normal errno).

This is a good point which I had not considered.

My position is that errors during symbol resolution in lazy binding are
never recoverable.  If the error is not recoverable, there is no need to
do any unwinding at all.  We currently get this wrong for init/fini
(bug 24304).

Rich Felker brought up this matter in conjunction with IFUNC resolvers.
These can be called during relocation processing (from dlopen) or lazy
binding, when they themselves trigger lazy binding.  I think these
errors should not be recoverable, either, whether they happen during
relocation processing or lazy binding.  But there is a narrow edge case
(IFUNC resolver called during relocation processing which triggers lazy
binding which fails in symbol lookup) where we actually have user code
(the IFUNC resolver) on the stack, and we would have to unwind through
the trampoline/IFUNC resolver/dlopen sequence if wanted to make this
error recoverable.  (Which I think we should not do, but the discussion
is still open.)

But even that edge case only happens after dlopen, so at least it's not
in an async-signal-safe context.  But the user stack frame pretty much
kills the DWARF-based unwinding approach if it's something we need to
support.

Thanks,
Florian