This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] GCC side of .eh_frame_hdr support
- From: Richard Henderson <rth at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 12 Dec 2001 12:58:10 -0800
- Subject: Re: [PATCH] GCC side of .eh_frame_hdr support
- References: <20011212184718.L1017@sunsite.ms.mff.cuni.cz>
On Wed, Dec 12, 2001 at 06:47:18PM +0100, Jakub Jelinek wrote:
> What's missing is
> a) If HAVE_LD_EH_FRAME_HDR is defined, %{!static:--eh-frame-hdr} needs to be
> somehow added to LINK_SPEC. Any suggestions how to do it? Changing
> all Linux/Hurd LINK_SPEC definitions in config.h files is something I'd
> like to avoid, furthermore we need to avoid string concatenation...
init_spec.
But --eh-frame-hdr also optimizes .eh_frame, so I don't necessarily
think that we need to remove it from static.
> b) As dl_iterate_phdr is guaranteed to work for dynamically linked programs
> only (just on IA-64 it works for statically linked too and on other
> platforms it is difficult to do), I think we'll need separate
> crtbeginT.o (T for static) on the platforms where this matters
> (so that crtbegin.o and crtbeginS.o don't call __(de)register_frame*
> for dynamically linked progs/shared libraries, but call it for -static).
> What do you think about it?
We could do that, or we could play games with weak references
to hidden symbols in crtbegin.o. There are other possible
solutions as well.
> +#ifdef _Unwind_Find_FDE
> +static
> +#endif
> fde *
> _Unwind_Find_FDE (void *pc, struct dwarf_eh_bases *bases)
Shouldn't need this? Or does it twig a -Wtraditional warning?
r~