Re: performance of exception handling

[Florian Weimer <fweimer@redhat.com>]

* Thomas Neumann:

>> Link: <https://wg21.link/P0709>
>> 
>> I'm not sure if your summary is correct.
>
> I was referring to Section 3.2, where Herb says:
>
> "We must remove all technical reasons for a C++ project to disable
> exception handling (e.g., by compiler switch) or ban use of exceptions,
> in all or part of their project."

Ah, but I think his other papers make it clear that he wants a unified
error handling mechanism for C++, but something that is not based on
exceptions with stack unwinding.  Or has he changed his mind?

> In a way I am disagreeing with the paper, of course, in that I propose
> to make the existing exception mechanism faster instead of inventing a
> new exception mechanism. But what I agree on with P0709 is that it is
> unfortunate that many projects disable exceptions due to performance
> concerns. And I think the performance problems can be solved.

Yes, I think we agree.

>> My current preferred solution is something that moves the entire code
>> that locates the relevant FDE table into glibc.
>
> That is indeed an option, but I have two concerns there. First, it will
> lead to code duplication, as libgcc will have to continue to provide its
> on implementation on systems with "old" glibcs lacking
> __dl_ehframe_find.

That's true for any approach with backwards compatibility.

> And second, libgcc has a second lookup mechanism for
> __register_frame_info_bases etc., which is needed to JITed code anyway.
> And it seems to be attractive to handle that in the same data structure
> that also covers the code from executables and shared libraries.

That would still need dynamic linker changes because currently, it is
not possible to report failure from an ELF constructor, and registration
may fail due to the memory allocations.

> Of course one could move that part to glibc, too. But the code
> duplication problems will persist for a long time, as gcc cannot rely
> upon the system glibc being new enough to provide __dl_ehframe_find.

Sure.  I'm not too worried about the explicitly registration code.  We
can optimize that independently, with a fast path for the common case
that no frames have been registered using this mechanism.

Thanks,
Florian