This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [PATCH] Next attempt on the gcc3 vs glibc2.2.4 patch
- To: Christoph Hellwig <hch at ns dot caldera dot de>
- Subject: Re: [PATCH] Next attempt on the gcc3 vs glibc2.2.4 patch
- From: Jakub Jelinek <jakub at redhat dot com>
- Date: Mon, 6 Aug 2001 13:21:05 -0400
- Cc: libc-alpha at sources dot redhat dot com, rth at redhat dot com, hjl at gnu dot org
- References: <20010806164136.K12476@sunsite.ms.mff.cuni.cz> <200108061716.f76HGZH15155@ns.caldera.de>
- Reply-To: Jakub Jelinek <jakub at redhat dot com>
On Mon, Aug 06, 2001 at 07:16:35PM +0200, Christoph Hellwig wrote:
> In article <20010806164136.K12476@sunsite.ms.mff.cuni.cz> you wrote:
> > Here is an updated version of the GCC 3.0 vs. GLIBC 2.2.4 patch.
> > Unlike the previous one, it does not care which gcc was used to build GLIBC
> > - everywhere but on Linux/IA-64 it exports the new GCC 3.0 unwind
> > register/deregister routines plus _Unwind_Find_FDE (using gcc's
> > unwind-dw2-fde.c with just a few changes for glibc), plus on platforms which
> > used to export __frame_state_for from glibc it does so.
>
> Is there any specific reason why you don't do on Linux/IA64?
Of course.
On IA-64 PT_IA_64_UNWIND ELF segment points to it and Richard's fde-glibc
finds the unwind tables just by walking _dl_load list (I've updated this to
dl_iterate_phdr@@GLIBC_2.2.4 interface recently, just need to test newer
version of that patch with both pre-2.2.4 and 2.2.4 glibc).
Thus no binary/library needs to register its eh_frame section (and does not
do that), so there is no point in providing those functions.
Jakub