From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5266 Path: news.gmane.org!not-for-mail From: "writeonce@midipix.org" Newsgroups: gmane.linux.lib.musl.general Subject: gcc'c crtstuff.c: a musl-related experience Date: Sun, 15 Jun 2014 17:36:37 -0400 Message-ID: <539E11E5.2080004@midipix.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1402868213 21449 80.91.229.3 (15 Jun 2014 21:36:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 15 Jun 2014 21:36:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5271-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jun 15 23:36:46 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WwI6Y-0001pW-Jt for gllmg-musl@plane.gmane.org; Sun, 15 Jun 2014 23:36:46 +0200 Original-Received: (qmail 20138 invoked by uid 550); 15 Jun 2014 21:36:45 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 20128 invoked from network); 15 Jun 2014 21:36:44 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 Xref: news.gmane.org gmane.linux.lib.musl.general:5266 Archived-At: Greetings, I thought I should share a recent experience that I had while building a cross compiler for i686-unknown-linux with x86_64 as a host. The problem I encountered (and now solved) is yet another "penalty" for me deviating from the norm, which in this case is gcc's way of hard-coding libc-specific features into the toolchain (mglibc, muclibc, etc.) As my toolchain does not provide such options, the compiler was mistakenly thinking that glibc was the default, which led to the "incident" I'd like to describe. The two files at stake are gcc/linux.h, and libgcc/crtstuff.c. In the former, a built-in macro named __gnu_linux__ is defined when glibc is the toolchain's default libc (OPTION_GLIBC). In the latter, a macro named USE_PT_GNU_EH_FRAME is defined when __gnu_linux__ is defined, which accordingly prevents USE_EH_FRAME_REGISTRY from being defined shortly thereafter. The absence of this last macro results in a crtbegin.o that is incompatible with musl, at least in some cases (a simple c++ application crashes after an exception has been thrown, which is how I came to notice it). The resulting file crtbegin.o is installed in one of the toolchain's directories, and is thus shared between all the libc's targeted by the toolchain. This means that when the toolchain's default libc is glibc, specifying -mmusl would result in a binary that has an incompatible crtbegin.o, at least in the above environment (i686 running on x86_64). To complete the picture: in the musl-cross toolchains, glibc is _not_ the default libc, and __gnu_linux_ is accordingly not defined. All you need to do in order to reproduce the above bug is moving around the options so that glibc becomes the default. With the current code of crtstuff.c, one easy way to avoid the bug while still keeping -mglibc, -mmusl, etc. is to "manually" define USE_EH_FRAME_REGISTRY. Not ideal, but still works. zg