On a system whose linker supports --eh-frame-hdr, we will use the version of
_Unwind_Find_FDE in unwind-dw2-fde-dip.c. It will override the version in
unwind-dw2-fde.c by renaming it via #define. This file is selected by
libgcc/config/t-eh-dw2-dip. It will still call the version of
_Unwind_Find_FDE, but that function will only look through files registered by
__register_frame_info_bases. __register_frame_info_bases is called by
crtstuff.c, but it is only called on systems whose linker does not support
On PT_GNU_EH_FRAME targets, even __register_frame_info_bases isn't
defined/used, we still include unwind-dw2-fde.c and call its
_Unwind_Find_FDE as _Unwind_Find_registered_FDE. Should we skip
the whole thing?
It is needed by crtbeginT.o for -static since PT_GNU_EH_FRAME isn't
used for static executables. However, dl_iterate_phdr works fine
with libc.a from glibc. Jakub, do you remember why PT_GNU_EH_FRAME
isn't used on static executables?
Think about libraries built with older GCC versions or built with older binutils. Those would still call the register routines instead of building .eh_frame_hdr.
(In reply to comment #2)
> Think about libraries built with older GCC versions or built with older
> binutils. Those would still call the register routines instead of building
We are talking static executables here. .eh-frame-hdr section is generated by
the linker to create static executable and we know --eh-frame-hdr works with
the linker. Why shouldn't --eh-frame-hdr work for static executable linked
with libraries built with older GCC versions or built with older binutils?
The old interface is needed for DSO and executable created by
the older binutils. However, it has nothing to with -static.
Also for Android targets, there is no old DSO.
-static -flto may not work without --eh-frame-hdr:
since LTO may pull in object files after crtend.o.