This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]