Re: gold vs libc

[Ian Lance Taylor <iant@google.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