> 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." 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. > 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. 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. 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. Thomas
