From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26938 invoked by alias); 5 Jul 2012 22:29:15 -0000 Received: (qmail 26928 invoked by uid 22791); 5 Jul 2012 22:29:14 -0000 X-SWARE-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Jul 2012 22:29:01 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1SmuXj-0005D0-UK from joseph_myers@mentor.com for libc-ports@sourceware.org; Thu, 05 Jul 2012 15:28:59 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jul 2012 15:28:09 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Thu, 5 Jul 2012 23:28:58 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1SmuXh-0005Bx-1u for libc-ports@sourceware.org; Thu, 05 Jul 2012 22:28:57 +0000 Date: Thu, 05 Jul 2012 22:29:00 -0000 From: "Joseph S. Myers" To: Subject: Add ARM-specific static-stubs.c Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2012-07/txt/msg00013.txt.bz2 While the ARM changes I included with my patch to avoid libgcc_s / libgcc_eh were sufficient to keep the ARM glibc build working in cases that had already worked without special hacks, it turns out they weren't quite sufficient to get the ARM build to start working when using a compiler without libgcc_s / libgcc_eh. With such a compiler, some of the unwind functionality is present in libgcc.a (whereas with a compiler built with shared libgcc, it's separate in libgcc_s and libgcc_eh). The copy of _Unwind_Resume from static-stubs.c is properly used in static links - but libgcc gets used before ARM's libgcc-stubs.a, so __aeabi_unwind_cpp_pr* get pulled in from libgcc, which ends up conflicting with the copy of _Unwind_Resume from static-stubs.c. So in fact the stub __aeabi_unwind_cpp_pr* need providing in two places: * In static-stubs.c (via a #include of aeabi_unwind_cpp_pr1.c), for static links with a compiler with libgcc.a only. * In libgcc-stubs.a, for linking other executables and shared libraries. I've applied this patch to get the ARM build working with a compiler with static-only libgcc, though I'll think some more about whether better approaches are possible. diff --git a/ports/ChangeLog.arm b/ports/ChangeLog.arm index 71e8b1b..8cd383d 100644 --- a/ports/ChangeLog.arm +++ b/ports/ChangeLog.arm @@ -1,3 +1,7 @@ +2012-07-05 Joseph Myers + + * sysdeps/arm/static-stubs.c: New file. + 2012-07-03 Joseph Myers * sysdeps/arm/Makefile (gnulib-arch): New variable. diff --git a/ports/sysdeps/arm/static-stubs.c b/ports/sysdeps/arm/static-stubs.c new file mode 100644 index 0000000..d90d603 --- /dev/null +++ b/ports/sysdeps/arm/static-stubs.c @@ -0,0 +1,7 @@ +/* When building with GCC with static-only libgcc, the dummy + _Unwind_Resume from static-stubs.c needs to be used together with + the dummy __aeabi_unwind_cpp_pr* from aeabi_unwind_cpp_pr1.c + instead of the copies from libgcc. */ + +#include +#include -- Joseph S. Myers joseph@codesourcery.com