Re: [PATCH] GCC side of .eh_frame_hdr support

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, Dec 12, 2001 at 12:58:10PM -0800, Richard Henderson wrote:
> 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.

Is some compiler other than gcc creating .eh_frame sections (with different
augmentation)?
If not, ld could do the .eh_frame optimizations unconditionally (provided it
understands it) and --eh-frame-hdr could only request .eh_frame_hdr
creation.

> > 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.

Can you please show me what exact code do you had in mind? Wouldn't it need
runtime lookups?

> > +#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?

I added it so that _Unwind_Find_registered_FDE is not exported from
libgcc.a. The fewer internal routines visible out of libgcc.a, the better.

	Jakub