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
On Wed, Dec 12, 2001 at 04:28:08PM -0500, Jakub Jelinek wrote:
> Is some compiler other than gcc creating .eh_frame sections (with different
> augmentation)?
Not to my knowledge.
> 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.
Yes, with the optimizations suppressed by --traditional-format.
> > 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?
I think it's moderately safe to assume that .text is on the same
page as the Ehdr for static programs. So you'd be able to do
.text
.global __gcc_static_text_start
.hidden __gcc_static_text_start
__gcc_static_text_start:
in, say, crtbegin.o. Then do
// test for registered,
// test for dl_iterate_phdr
// last, see if this is a static executable
extern char __gcc_static_text_start[] __attribute__((weak));
if (__gcc_static_text_start)
{
ElfW(Ehdr) *ehdr = (ElfW(Ehdr) *)
((size_t)__gcc_static_text_start & PAGE_MASK);
// test for magic numbers etc.
}
> 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.
Yes, but the static prototype makes the function static. In ISO C,
the declaration and the definition don't have to match.
r~