* David Edelsohn: > 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.
Sorry, if I gave the impression that we should remove any code from libgcc/ or start requiring support for dl_iterate_phdr, that was not my intention. Florian
