This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: gold vs libc
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: "GNU C. Library" <libc-alpha at sourceware dot org>, binutils at sourceware dot org
- Date: Sat, 29 Mar 2014 22:06:15 -0700 (PDT)
- Subject: Re: gold vs libc
- Authentication-results: sourceware.org; auth=none
- References: <20140330042516 dot 1A88E74481 at topped-with-meat dot com> <20140330045552 dot GX18201 at bubble dot grove dot modra dot org>
> https://sourceware.org/bugzilla/show_bug.cgi?id=14675
Thanks. In fact, CFI in crt1.o is useful for the debugger (which doesn't
care where __EH_FRAME_BEGIN__ points). See:
https://sourceware.org/ml/libc-alpha/2012-03/msg00573.html
for why we added it.
In the (more common) dynamic linking case, it works fine because
__EH_FRAME_BEGIN__ is not used. Insteaad, --eh-frame-hdr is used at link
time so PT_GNU_EH_FRAME can be used at runtime. I don't know why we don't
do it that way for static linking too. The binary-search table is a
worthwhile optimization for everybody.
AFAICT if we just started passing --eh-frame-hdr and stopped using
crt{begin,end}T.o instead of crt{begin,end}.o under -static it would work
as is. dl_iterate_phdr in the static case should already find the
program's own phdr so libgcc can find PT_GNU_EH_FRAME in there and be happy.
But given the status quo, gold should do something more like what ld does.
Thanks,
Roland