This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [Patch] Unterminated .eh_frame when using --eh-frame-hdr
Richard Henderson <rth@twiddle.net> writes:
> On Fri, Nov 12, 2004 at 09:43:17AM +0000, Richard Sandiford wrote:
>> - introduce a new macro, HAVE_DWARF2_UNWIND_INFO_REGISTRY to
>> control whether calls to the registry routines are needed.
>
> This is the part that Uli probably objects to more than anything
> else -- why should any port not support .eh_frame_hdr? It does
> seem better to spend the time fixing the linker than doing ugly
> things to the glibc configury.
I'm not following, sorry. What do you mean by fixing the linker?
The linker is already generating an .eh_frame_hdr section. What it's
not doing is generating the optional list of FDEs. That seems valid
given the circumstances and the spec of the .eh_frame_hdr format.
When Uli said "fix the linker", I thought he meant: "Make sure it
always generates the sorted list of FDEs. That way, we don't need
the .eh_frame zero terminator". But as you said in your earlier reply:
The proper fix is to *always* emit the terminal zero, without
regard to the configury. Failure to do so means the data is
not in the correct format.
I took that to mean that .eh_frame must always be zero-terminated,
even if there's an .eh_frame_hdr section. libc isn't doing that
at present: see the libc.so .eh_frame from FC2 for an example.
So I assume you mean something different by "fix the linker" ;)
To recap: as far as the configure script is concerned, we already have
four modes of .eh_frame support (including none at all). All my patch
is trying to do is fix the .eh_frame info generated for one of them.
I'm not trying to introduce yet another mode.
------------
You say "why should any port not support .eh_frame_hdr?". I thought the
no-.eh_frame_hdr case was there for compatibility with older toolchains.
Are you saying that that case is no longer needed, and that we can
always assume that the linker supports --eh-frame-hdr? I.e. that
we should combine the existing:
libc_cv_gcc_dwarf2_unwind_info=no_registry_needed
libc_cv_gcc_dwarf2_unwind_info=yes
cases and patch soinit.c so that registry functions are only called
if HAVE_DWARF2_UNWIND_INFO_STATIC?
Richard