This is the mail archive of the
mailing list for the binutils project.
Re: PATCH: PR gold/14675: No eh_frame info registered in exception_static_test
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Cary Coutant <ccoutant at google dot com>
- Cc: Ian Lance Taylor <iant at google dot com>, Roland McGrath <roland at hack dot frob dot com>, Alan Modra <amodra at gmail dot com>, Binutils <binutils at sourceware dot org>, Rafael Ãvila de EspÃndola <rafael dot espindola at gmail dot com>
- Date: Mon, 26 Jan 2015 09:21:59 -0800
- Subject: Re: PATCH: PR gold/14675: No eh_frame info registered in exception_static_test
- Authentication-results: sourceware.org; auth=none
- References: <20140331200446 dot A09B074430 at topped-with-meat dot com> <CAKOQZ8x19YZ_oyJXyxe9JST4nfaG8dDvVrdf-vmgkNWydrpsrw at mail dot gmail dot com> <20140331214025 dot E61517447E at topped-with-meat dot com> <CAKOQZ8x1W0YxJSq+X74EjMj7_02uTZq82qzhmF=oQ-cTd4S1mQ at mail dot gmail dot com> <CAHACq4oRKDGKAUu3octDCxKg2EueCyf8kHWj0t8g9+LmE3JagQ at mail dot gmail dot com> <20140910225238 dot 0B6362C39CF at topped-with-meat dot com> <CAKOQZ8zW_zbR1Tog6HWak9T4d9gXMd9iK=PenQq2E5u-kiNr6Q at mail dot gmail dot com> <20141220135811 dot GA7161 at gmail dot com> <CAHACq4r6f_dGg5fB=mcrdcQMHcERRVnTBVyJTSrh8YTsWCNTBQ at mail dot gmail dot com> <20150107131655 dot GA7818 at gmail dot com> <20150107144300 dot GA498 at gmail dot com> <CAHACq4qAXVM3RTmuu2yf6qe+iwkhXzzeycYY34fkjpOdWp3=-g at mail dot gmail dot com>
On Wed, Jan 7, 2015 at 10:50 AM, Cary Coutant <firstname.lastname@example.org> wrote:
> Thanks for looking at this, but I find this a bit much for what it
> does -- it's pretty intrusive, and still doesn't even do the right
> thing with the eh info from crt1.o (which is still placed before the
> __EH_FRAME_BEGIN__ symbol, and will be ignored).
> I really dislike special-cases based on filename. At one point in the
> discussion, Roland suggested recognizing crtbeginT.o by the fact that
> it has a relocation to the .eh_frame section symbol. I think it may be
> even simpler than that, though -- given that the endcap in crtend.o
> has a non-zero length, I think it's safe to put all zero-length
> .eh_frame sections in front of the optimized data. That should have
> the desired affect for crtbeginT.o. Let me give that a try.
Do we have any progress on this?