On Mon, May 11, 2020 at 10:52 AM Florian Weimer <fwei...@redhat.com> wrote: > > * David Edelsohn: > > > On Mon, May 11, 2020 at 6:47 AM Florian Weimer via Gcc <gcc@gcc.gnu.org> > > wrote: > > > >> My current preferred solution is something that moves the entire code > >> that locates the relevant FDE table into glibc. This is all the code in > >> _Unwind_IteratePhdrCallback until the first read_encoded_value_with_base > >> call. And the callback mechanism would be gone, so _Unwind_Find_FDE > >> would call __dl_ehframe_find (see below) and then the reamining > >> processing in _Unwind_IteratePhdrCallback. > > > > Not all GCC/G++ targets are GNU/Linux and use GLIBC. A duplicate > > implementation in GLIBC creates its own set of advantages and > > disadvantages. > > The new interface is no less generic than _dl_iterate_phdr, so other > systems can easily implement it if they want (and reuse the libgcc code > that uses it).
The mission of GCC explicitly states that it supports other platforms and diverse environments. Other targets may or may not be able to modify their C Library. GLIBC is free to implement a more optimal API and coordinate with GCC, but GCC EH cannot rely on a new, optional, ad hoc interface provided by GLIBC. Thanks, David
