This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: gold vs libc
- From: Ian Lance Taylor <iant at google dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Alan Modra <amodra at gmail dot com>, "GNU C. Library" <libc-alpha at sourceware dot org>, Binutils <binutils at sourceware dot org>
- Date: Mon, 31 Mar 2014 12:03:31 -0700
- 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> <20140330050615 dot 7DC5774481 at topped-with-meat dot com>
On Sat, Mar 29, 2014 at 10:06 PM, Roland McGrath <roland@hack.frob.com> wrote:
>> 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.
I don't fully understand this, but it seems to me that gold's
behaviour is correct and GNU ld's behaviour is incorrect. GNU ld is
effectively discarding the exception frame information in crt1.o, and
gold is retaining it.
To put it another way: what principle should gold follow to get the
result you want?
Ian