From owner-freebsd-toolchain@FreeBSD.ORG Sun Aug 21 00:46:35 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC3EF1065670; Sun, 21 Aug 2011 00:46:35 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 88A418FC08; Sun, 21 Aug 2011 00:46:35 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:55e9:5579:6ddd:60ab] (unknown [IPv6:2001:7b8:3a7:0:55e9:5579:6ddd:60ab]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C8A025C37; Sun, 21 Aug 2011 02:46:34 +0200 (CEST) Message-ID: <4E50551D.9020104@FreeBSD.org> Date: Sun, 21 Aug 2011 02:45:17 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Alexander Best References: <20110818050142.GA96873@freebsd.org> <4E4CB59B.3000005@FreeBSD.org> <20110818173508.GA92360@freebsd.org> <4E4D6E01.40905@FreeBSD.org> <20110819080105.GA92201@freebsd.org> In-Reply-To: <20110819080105.GA92201@freebsd.org> Content-Type: multipart/mixed; boundary="------------020507060807000600080109" Cc: freebsd-toolchain@freebsd.org Subject: Re: Relocatable linking with relocations from format elf64-x86-64-freebsd (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 00:46:35 -0000 This is a multi-part message in MIME format. --------------020507060807000600080109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2011-08-19 10:01, Alexander Best wrote: > On Thu Aug 18 11, Dimitry Andric wrote: ... >> Please use the following fragment instead, which is recommended on >> : > thanks. that fixed the issue. seeing forward to simply setting CC/CXX/CPP to > clang or gcc directly and also to using "/", so one can use absolute paths. Please try the attached patch, which makes it possible to set CC and CXX in make.conf, while allowing the build32 stage to still override them. Explanation: 1) The build32 stage sets environment variables CC, CXX, AS and LD for its sub-make, to add 32-bit specific flags (-m32 and such). 2) The sub-make reads sys.mk, encounters CC?= and CXX?= assignments, so does not alter them. 3) After some other stuff, sys.mk reads /etc/make.conf. When you have "CC=xxx" and "CXX=yyy" statements in there, they will *override* the build32-supplied CC/CXX values, nullifying the 32-bit specific flags. 4) Thus all objects get built as 64-bit anyway, and since LD is usually not set in make.conf, it still has the 32-bit flags! 5) Now, whenever something is linked, you will get a "ld: Relocatable linking with relocations from format elf64-x86-64-freebsd (foo.o) to format elf32-i386-freebsd (bar.o) is not supported" error. The patch fixes this by adding "-ECC -ECXX -EAS -ELD" to the build32 sub-make invocation, which forces those environment variables to always override any assignment in makefiles. It makes it possible to simply do: CC=clang CXX=clang++ in your make.conf, or specify a path, even: CC=/usr/local/bin/gcc46 CXX=/usr/local/bin/g++46 Note this was already possible on i386, but not yet on amd64. Also, strange things might happen if you set CC but not CXX, or vice versa... --------------020507060807000600080109 Content-Type: text/plain; name="build32-override-cc-cxx-as-ld-1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="build32-override-cc-cxx-as-ld-1.diff" Index: Makefile.inc1 =================================================================== --- Makefile.inc1 (revision 224934) +++ Makefile.inc1 (working copy) @@ -313,7 +313,8 @@ LIB32WMAKE= ${LIB32WMAKEENV} ${MAKE} -DNO_CPU_CFLAGS -DCOMPAT_32BIT \ -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO \ - -DWITHOUT_HTML -DNO_CTF -DNO_LINT DESTDIR=${LIB32TMP} + -DWITHOUT_HTML -DNO_CTF -DNO_LINT -ECC -ECXX -EAS -ELD \ + DESTDIR=${LIB32TMP} LIB32IMAKE= ${LIB32WMAKE:NINSTALL=*:NDESTDIR=*} -DNO_INCS .endif --------------020507060807000600080109-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Aug 21 09:37:06 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AD85106566C for ; Sun, 21 Aug 2011 09:37:06 +0000 (UTC) (envelope-from ttsestt@gmail.com) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx1.freebsd.org (Postfix) with ESMTP id 9D2098FC15 for ; Sun, 21 Aug 2011 09:37:05 +0000 (UTC) Received: by iye7 with SMTP id 7so16304716iye.17 for ; Sun, 21 Aug 2011 02:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:user-agent:mime-version :content-type; bh=EUhI8qiOGe1VEVG6FlfYTPoW9WItyq+cdcND3z0r9uI=; b=PMyqlB4JbRuo174Hycafx5CfJEDB64+lSiQNbBMLBeLLrzcWFBjTr+VTs1Lwhs0P4F LlTB9I6cxDUlNl6xYwnySigB6NCRmYI4Ad8ptycT67ty95FZQZRXAh1Tfu5de2r2fteX KkQlqg6zpLWoQq9qXN1O5HL9EnLJR9vXbO0Sc= Received: by 10.42.155.4 with SMTP id s4mr1366475icw.497.1313917714639; Sun, 21 Aug 2011 02:08:34 -0700 (PDT) Received: from localhost (tor-exit-router39-readme.formlessnetworking.net [199.48.147.39]) by mx.google.com with ESMTPS id m21sm2681183ibf.42.2011.08.21.02.08.32 (version=SSLv3 cipher=OTHER); Sun, 21 Aug 2011 02:08:33 -0700 (PDT) From: Test Rat To: freebsd-toolchain@freebsd.org Date: Sun, 21 Aug 2011 13:08:25 +0400 Message-ID: <86fwkvt9me.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Subject: [clang] rtld-elf/rtld.c and stack traces in gdb(1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 09:37:06 -0000 I often get corrupted traces with clang world, the cause seems to be in rtld. $ cd /usr/src/libexec/rtld-elf; env -i __MAKE_CONF=/dev/null TERM=$TERM sh $ make CC=gcc all install $ gdb yes [...] y y ^C Program received signal SIGINT, Interrupt. 0x00000008009455ac in write () from /lib/libc.so.7 (gdb) bt #0 0x00000008009455ac in write () from /lib/libc.so.7 #1 0x0000000800944fa7 in _swrite (fp=, buf=, n=) at /usr/src/lib/libc/stdio/stdio.c:133 #2 0x0000000800944c7b in __fflush (fp=) at /usr/src/lib/libc/stdio/fflush.c:123 #3 0x000000080094412d in __sfvwrite (fp=, uio=) at /usr/src/lib/libc/stdio/fvwrite.c:194 #4 0x000000080091c434 in puts (s=) at /usr/src/lib/libc/stdio/puts.c:68 #5 0x00000000004005fa in main (argc=, argv=find_location_expression: Corrupted DWARF expression. ) at /usr/src/usr.bin/yes/yes.c:54 $ touch rtld.c $ PATH=/usr/bin:$PATH make CC=clang all install $ gdb yes [...] y y ^C Program received signal SIGINT, Interrupt. 0x00000008009455ac in ?? () (gdb) bt #0 0x00000008009455ac in ?? () #1 0x0000000800944fa7 in ?? () #2 0x0000000000000002 in ?? () #3 0x000000080094d560 in ?? () #4 0x0000000800b73560 in ?? () #5 0x0000000800c08000 in ?? () #6 0x00007fffffffd160 in ?? () #7 0x0000000800944c7b in ?? () #8 0x0000000000000001 in ?? () #9 0x0000000000000001 in ?? () #10 0x0000000000000001 in ?? () #11 0x0000000800b73560 in ?? () #12 0x00007fffffffd1c0 in ?? () #13 0x000000080094412d in ?? () #14 0x00007fffffffc648 in ?? () #15 0x0000000000000001 in ?? () #16 0x0000000100400656 in ?? () #17 0x00007fffffffd1f8 in ?? () #18 0x00007fffffffd1f8 in ?? () #19 0x0000000000400656 in _fini () #20 0x00007fffffffd280 in ?? () #21 0x0000000000000000 in ?? () And compiling rtld with clang + -O0 makes it crash. -- FreeBSD 9.0-BETA1 r225055M amd64 From owner-freebsd-toolchain@FreeBSD.ORG Sun Aug 21 15:41:24 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 6FC931065672; Sun, 21 Aug 2011 15:41:24 +0000 (UTC) Date: Sun, 21 Aug 2011 15:41:24 +0000 From: Alexander Best To: Dimitry Andric Message-ID: <20110821154124.GA12064@freebsd.org> References: <20110818050142.GA96873@freebsd.org> <4E4CB59B.3000005@FreeBSD.org> <20110818173508.GA92360@freebsd.org> <4E4D6E01.40905@FreeBSD.org> <20110819080105.GA92201@freebsd.org> <4E50551D.9020104@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E50551D.9020104@FreeBSD.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: Relocatable linking with relocations from format elf64-x86-64-freebsd (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 15:41:24 -0000 On Sun Aug 21 11, Dimitry Andric wrote: > On 2011-08-19 10:01, Alexander Best wrote: > >On Thu Aug 18 11, Dimitry Andric wrote: > ... > >>Please use the following fragment instead, which is recommended on > >>: > >thanks. that fixed the issue. seeing forward to simply setting CC/CXX/CPP > >to > >clang or gcc directly and also to using "/", so one can use absolute paths. > > Please try the attached patch, which makes it possible to set CC and CXX > in make.conf, while allowing the build32 stage to still override them. > > Explanation: > 1) The build32 stage sets environment variables CC, CXX, AS and LD for > its sub-make, to add 32-bit specific flags (-m32 and such). > 2) The sub-make reads sys.mk, encounters CC?= and CXX?= assignments, so > does not alter them. > 3) After some other stuff, sys.mk reads /etc/make.conf. When you have > "CC=xxx" and "CXX=yyy" statements in there, they will *override* the > build32-supplied CC/CXX values, nullifying the 32-bit specific flags. > 4) Thus all objects get built as 64-bit anyway, and since LD is usually > not set in make.conf, it still has the 32-bit flags! > 5) Now, whenever something is linked, you will get a "ld: Relocatable > linking with relocations from format elf64-x86-64-freebsd (foo.o) to > format elf32-i386-freebsd (bar.o) is not supported" error. > > The patch fixes this by adding "-ECC -ECXX -EAS -ELD" to the build32 > sub-make invocation, which forces those environment variables to always > override any assignment in makefiles. > > It makes it possible to simply do: > > CC=clang > CXX=clang++ > > in your make.conf, or specify a path, even: > > CC=/usr/local/bin/gcc46 > CXX=/usr/local/bin/g++46 > > Note this was already possible on i386, but not yet on amd64. Also, > strange things might happen if you set CC but not CXX, or vice versa... thanks a bunch. both buildworld and buildkernel succeeded with CC, CXX and CPP set explicitly to the absolute clang location. :) cheers. alex > Index: Makefile.inc1 > =================================================================== > --- Makefile.inc1 (revision 224934) > +++ Makefile.inc1 (working copy) > @@ -313,7 +313,8 @@ > > LIB32WMAKE= ${LIB32WMAKEENV} ${MAKE} -DNO_CPU_CFLAGS -DCOMPAT_32BIT \ > -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO \ > - -DWITHOUT_HTML -DNO_CTF -DNO_LINT DESTDIR=${LIB32TMP} > + -DWITHOUT_HTML -DNO_CTF -DNO_LINT -ECC -ECXX -EAS -ELD \ > + DESTDIR=${LIB32TMP} > LIB32IMAKE= ${LIB32WMAKE:NINSTALL=*:NDESTDIR=*} -DNO_INCS > .endif > From owner-freebsd-toolchain@FreeBSD.ORG Sun Aug 21 19:11:27 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21733106566C for ; Sun, 21 Aug 2011 19:11:27 +0000 (UTC) (envelope-from ttsestt@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id A97438FC15 for ; Sun, 21 Aug 2011 19:11:26 +0000 (UTC) Received: by fxe4 with SMTP id 4so3878465fxe.13 for ; Sun, 21 Aug 2011 12:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-type; bh=hHCnFXV4G9jpyx3w9VHN9AvW6dLohON8fBuhISicq+I=; b=gWp3hBeiweUdVkGQjpQiGaQVmZWltlXoLHvKkcJcAn3xdFhmwIZm62nBaBI+pr/N7B PLlT/7YSJ7Y5tJla96sfl5l5R21/Q+IItdQ9xDGiqwUQ6QyNh+FoUMGYpqWyWlL8201w AWK8oVY9FYFxzq28ubBL5280aeCGgzjuUq6y4= Received: by 10.223.88.214 with SMTP id b22mr2449292fam.5.1313953885263; Sun, 21 Aug 2011 12:11:25 -0700 (PDT) Received: from localhost (tor.cinipac.net [79.172.193.89]) by mx.google.com with ESMTPS id n7sm961973faa.2.2011.08.21.12.11.23 (version=SSLv3 cipher=OTHER); Sun, 21 Aug 2011 12:11:24 -0700 (PDT) From: Test Rat To: Roman Divacky References: <86fwkvt9me.fsf@gmail.com> <20110821172025.GA6711@freebsd.org> Date: Sun, 21 Aug 2011 23:11:10 +0400 Message-ID: <86ty9aa8c1.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-toolchain@freebsd.org Subject: Re: [clang] rtld-elf/rtld.c and stack traces in gdb(1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 19:11:27 -0000 Roman Divacky writes: >> And compiling rtld with clang + -O0 makes it crash. > > what is "it" ? clang itself or rtld? rtld, but not on trunk (r138219) > Also I think it makes sense to check if this issue persists with TOT > clang, can you check that? It persists. Compiling only rtld.c with -O0 seems to be a workaround. From owner-freebsd-toolchain@FreeBSD.ORG Mon Aug 22 14:34:09 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 295721065672 for ; Mon, 22 Aug 2011 14:34:09 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id E6FA88FC19 for ; Mon, 22 Aug 2011 14:34:08 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id A52BF7F3892; Mon, 22 Aug 2011 16:18:15 +0200 (CEST) Date: Mon, 22 Aug 2011 16:18:15 +0200 From: Roman Divacky To: Test Rat Message-ID: <20110822141815.GA23361@freebsd.org> References: <86fwkvt9me.fsf@gmail.com> <20110821172025.GA6711@freebsd.org> <86ty9aa8c1.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86ty9aa8c1.fsf@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-toolchain@freebsd.org Subject: Re: [clang] rtld-elf/rtld.c and stack traces in gdb(1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 14:34:09 -0000 On Sun, Aug 21, 2011 at 11:11:10PM +0400, Test Rat wrote: > Roman Divacky writes: > > >> And compiling rtld with clang + -O0 makes it crash. > > > > what is "it" ? clang itself or rtld? > > rtld, but not on trunk (r138219) > > > Also I think it makes sense to check if this issue persists with TOT > > clang, can you check that? > > It persists. Compiling only rtld.c with -O0 seems to be a workaround. I am confused, so does it work or crash with O0? From owner-freebsd-toolchain@FreeBSD.ORG Tue Aug 23 09:23:01 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 2BD2B1065674; Tue, 23 Aug 2011 09:23:01 +0000 (UTC) Date: Tue, 23 Aug 2011 09:23:01 +0000 From: Alexander Best To: Dimitry Andric Message-ID: <20110823092301.GA45910@freebsd.org> References: <20110818050142.GA96873@freebsd.org> <4E4CB59B.3000005@FreeBSD.org> <20110818173508.GA92360@freebsd.org> <4E4D6E01.40905@FreeBSD.org> <20110819080105.GA92201@freebsd.org> <4E50551D.9020104@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E50551D.9020104@FreeBSD.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: Relocatable linking with relocations from format elf64-x86-64-freebsd (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 09:23:01 -0000 On Sun Aug 21 11, Dimitry Andric wrote: > On 2011-08-19 10:01, Alexander Best wrote: > >On Thu Aug 18 11, Dimitry Andric wrote: > ... > >>Please use the following fragment instead, which is recommended on > >>: > >thanks. that fixed the issue. seeing forward to simply setting CC/CXX/CPP > >to > >clang or gcc directly and also to using "/", so one can use absolute paths. > > Please try the attached patch, which makes it possible to set CC and CXX > in make.conf, while allowing the build32 stage to still override them. > > Explanation: > 1) The build32 stage sets environment variables CC, CXX, AS and LD for > its sub-make, to add 32-bit specific flags (-m32 and such). > 2) The sub-make reads sys.mk, encounters CC?= and CXX?= assignments, so > does not alter them. > 3) After some other stuff, sys.mk reads /etc/make.conf. When you have > "CC=xxx" and "CXX=yyy" statements in there, they will *override* the > build32-supplied CC/CXX values, nullifying the 32-bit specific flags. > 4) Thus all objects get built as 64-bit anyway, and since LD is usually > not set in make.conf, it still has the 32-bit flags! > 5) Now, whenever something is linked, you will get a "ld: Relocatable > linking with relocations from format elf64-x86-64-freebsd (foo.o) to > format elf32-i386-freebsd (bar.o) is not supported" error. > > The patch fixes this by adding "-ECC -ECXX -EAS -ELD" to the build32 > sub-make invocation, which forces those environment variables to always > override any assignment in makefiles. > > It makes it possible to simply do: > > CC=clang > CXX=clang++ > > in your make.conf, or specify a path, even: > > CC=/usr/local/bin/gcc46 > CXX=/usr/local/bin/g++46 > > Note this was already possible on i386, but not yet on amd64. Also, > strange things might happen if you set CC but not CXX, or vice versa... any chance this patch can be committed? cheers. alex > Index: Makefile.inc1 > =================================================================== > --- Makefile.inc1 (revision 224934) > +++ Makefile.inc1 (working copy) > @@ -313,7 +313,8 @@ > > LIB32WMAKE= ${LIB32WMAKEENV} ${MAKE} -DNO_CPU_CFLAGS -DCOMPAT_32BIT \ > -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO \ > - -DWITHOUT_HTML -DNO_CTF -DNO_LINT DESTDIR=${LIB32TMP} > + -DWITHOUT_HTML -DNO_CTF -DNO_LINT -ECC -ECXX -EAS -ELD \ > + DESTDIR=${LIB32TMP} > LIB32IMAKE= ${LIB32WMAKE:NINSTALL=*:NDESTDIR=*} -DNO_INCS > .endif > From owner-freebsd-toolchain@FreeBSD.ORG Tue Aug 23 09:34:13 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DADC61065670; Tue, 23 Aug 2011 09:34:13 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4C98FC0A; Tue, 23 Aug 2011 09:34:13 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:2cd0:314:6286:119c] (unknown [IPv6:2001:7b8:3a7:0:2cd0:314:6286:119c]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A484B5C59; Tue, 23 Aug 2011 11:34:12 +0200 (CEST) Message-ID: <4E537413.5070105@FreeBSD.org> Date: Tue, 23 Aug 2011 11:34:11 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Alexander Best References: <20110818050142.GA96873@freebsd.org> <4E4CB59B.3000005@FreeBSD.org> <20110818173508.GA92360@freebsd.org> <4E4D6E01.40905@FreeBSD.org> <20110819080105.GA92201@freebsd.org> <4E50551D.9020104@FreeBSD.org> <20110823092301.GA45910@freebsd.org> In-Reply-To: <20110823092301.GA45910@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-toolchain@freebsd.org Subject: Re: Relocatable linking with relocations from format elf64-x86-64-freebsd (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 09:34:13 -0000 On 2011-08-23 11:23, Alexander Best wrote: ... >> The patch fixes this by adding "-ECC -ECXX -EAS -ELD" to the build32 >> sub-make invocation, which forces those environment variables to always >> override any assignment in makefiles. >> >> It makes it possible to simply do: >> >> CC=clang >> CXX=clang++ >> >> in your make.conf, or specify a path, even: >> >> CC=/usr/local/bin/gcc46 >> CXX=/usr/local/bin/g++46 >> >> Note this was already possible on i386, but not yet on amd64. Also, >> strange things might happen if you set CC but not CXX, or vice versa... > > any chance this patch can be committed? I hope so, but it needs to be reviewed by one or more senior build gurus, before it makes a chance (if any) to get into 9.0-R. It's really just a band-aid now. Obviously, the whole way Makefile.inc1 sets up CC to run the build32 stage should be overhauled, and as Warner said, we really need a (SYSTEM|WORLD|PORTS)_COMPILER global switch (instead of manually setting CC), but that kind of restructuring must be done after the tree is unfrozen, not now. From owner-freebsd-toolchain@FreeBSD.ORG Tue Aug 23 21:35:04 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AD571065675 for ; Tue, 23 Aug 2011 21:35:04 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9ED928FC17 for ; Tue, 23 Aug 2011 21:35:03 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:2cd0:314:6286:119c] (unknown [IPv6:2001:7b8:3a7:0:2cd0:314:6286:119c]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 837635C59; Tue, 23 Aug 2011 23:35:02 +0200 (CEST) Message-ID: <4E541D02.1040506@FreeBSD.org> Date: Tue, 23 Aug 2011 23:34:58 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Test Rat References: <86fwkvt9me.fsf@gmail.com> In-Reply-To: <86fwkvt9me.fsf@gmail.com> Content-Type: multipart/mixed; boundary="------------020601090600040307020106" Cc: freebsd-toolchain@freebsd.org Subject: Re: [clang] rtld-elf/rtld.c and stack traces in gdb(1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 21:35:04 -0000 This is a multi-part message in MIME format. --------------020601090600040307020106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2011-08-21 11:08, Test Rat wrote: > I often get corrupted traces with clang world, the cause seems to be in rtld. ... > (gdb) bt > #0 0x00000008009455ac in ?? () > #1 0x0000000800944fa7 in ?? () After some digging, this turned out to be caused by the empty function r_debug_state() in libexec/rtld-elf/rtld.c. This function is just a necessary hook for gdb, but since it is completely empty, calls to it in the same compilation unit simply don't generate any code, even if the function is marked as __noinline. The attached patch fixes this, by marking the function __noinline, and inserting an empty asm statement, that pretends to clobber memory. It generates no extra code, and forces clang to emit calls to r_debug_state throughout rtld.c. It looks rather hackish, though. An alternative solution would be to move the r_debug_state() function to another .c file, which should work OK, until we eventually start using link time optimization... :) > And compiling rtld with clang + -O0 makes it crash. This is caused by yet another interesting problem, which is in the _rtld() function in rtld.c. It is run at the very beginning of rtld, when relocations have not yet been processed. This initial code must be very careful to *not* use any relocated symbols, or problems will arise. The early initialization goes like: ... /* Initialize and relocate ourselves. */ assert(aux_info[AT_BASE] != NULL); init_rtld((caddr_t) aux_info[AT_BASE]->a_un.a_ptr, aux_info); __progname = obj_rtld.path; argv0 = argv[0] != NULL ? argv[0] : "(null)"; environ = env; The init_rtld() function takes care of the initial relocations, after which 'global' symbols like __progname and environ can be used. However, at -O0, clang still reorders the retrieval of the __progname offset to just *before* the init_rtld() call, and assigns it afterwards: ... .LBB0_16: # %cond.end movq __progname@GOTPCREL(%rip), %rax <-- gets the offset here leaq -224(%rbp), %rsi .loc 1 329 5 # /usr/src/libexec/rtld-elf/rtld.c:329:5 movq -168(%rbp), %rcx movq 8(%rcx), %rdi movq %rax, -1504(%rbp) # 8-byte Spill <-- saves offset on stack callq init_rtld .loc 1 331 5 # /usr/src/libexec/rtld-elf/rtld.c:331:5 movq obj_rtld+24(%rip), %rax movq -1504(%rbp), %rcx # 8-byte Reload <-- loads offset from stack movq %rax, (%rcx) <-- stores value in __progname It's not clear to me why clang does this reordering even when optimization is off, but it is normally legal, and quite usual. However, in case of this early initialization, it is fatal, as __progname@GOTPCREL(%rip) will still be junk, or zero... With optimization, such reorderings are even more likely, but for some reason, we have always been lucky that it turned out OK. A possible solution would be to move the code after the init_rtld() call to another function, and call that, but this could also be defeated again by inlining. :( --------------020601090600040307020106 Content-Type: text/plain; name="fix-rtld-backtrace-2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="fix-rtld-backtrace-2.diff" Index: libexec/rtld-elf/rtld.c =================================================================== --- libexec/rtld-elf/rtld.c (revision 225105) +++ libexec/rtld-elf/rtld.c (working copy) @@ -143,7 +143,7 @@ static void ld_utrace_log(int, void *, void *, siz static void rtld_fill_dl_phdr_info(const Obj_Entry *obj, struct dl_phdr_info *phdr_info); -void r_debug_state(struct r_debug *, struct link_map *); +void r_debug_state(struct r_debug *, struct link_map *) __noinline; /* * Data declarations. @@ -2780,6 +2780,14 @@ linkmap_delete(Obj_Entry *obj) void r_debug_state(struct r_debug* rd, struct link_map *m) { + /* + * The following is a hack to force the compiler to emit calls to + * this function, even when optimizing. If the function is empty, + * the compiler is not obliged to emit any code for calls to it, + * even when marked __noinline. However, gdb depends on those + * calls being made. + */ + __asm __volatile("" : : : "memory"); } /* --------------020601090600040307020106-- From owner-freebsd-toolchain@FreeBSD.ORG Wed Aug 24 08:18:23 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 655A1106566B; Wed, 24 Aug 2011 08:18:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id F3F508FC0C; Wed, 24 Aug 2011 08:18:22 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p7O8IJ7A030121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2011 11:18:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p7O8IJq7054726; Wed, 24 Aug 2011 11:18:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p7O8IJ7Y054725; Wed, 24 Aug 2011 11:18:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 24 Aug 2011 11:18:19 +0300 From: Kostik Belousov To: Dimitry Andric Message-ID: <20110824081819.GI17489@deviant.kiev.zoral.com.ua> References: <86fwkvt9me.fsf@gmail.com> <4E541D02.1040506@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="g2QKYTO1/ZKqu+7N" Content-Disposition: inline In-Reply-To: <4E541D02.1040506@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Test Rat , freebsd-toolchain@freebsd.org Subject: Re: [clang] rtld-elf/rtld.c and stack traces in gdb(1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 08:18:23 -0000 --g2QKYTO1/ZKqu+7N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 23, 2011 at 11:34:58PM +0200, Dimitry Andric wrote: > On 2011-08-21 11:08, Test Rat wrote: > >I often get corrupted traces with clang world, the cause seems to be in= =20 > >rtld. > ... > > (gdb) bt > > #0 0x00000008009455ac in ?? () > > #1 0x0000000800944fa7 in ?? () >=20 > After some digging, this turned out to be caused by the empty function > r_debug_state() in libexec/rtld-elf/rtld.c. This function is just a > necessary hook for gdb, but since it is completely empty, calls to it in > the same compilation unit simply don't generate any code, even if the > function is marked as __noinline. >=20 > The attached patch fixes this, by marking the function __noinline, and > inserting an empty asm statement, that pretends to clobber memory. It > generates no extra code, and forces clang to emit calls to r_debug_state > throughout rtld.c. It looks rather hackish, though. >=20 > An alternative solution would be to move the r_debug_state() function to > another .c file, which should work OK, until we eventually start using > link time optimization... :) >=20 >=20 > >And compiling rtld with clang + -O0 makes it crash. >=20 > This is caused by yet another interesting problem, which is in the > _rtld() function in rtld.c. It is run at the very beginning of rtld, > when relocations have not yet been processed. This initial code must be > very careful to *not* use any relocated symbols, or problems will arise. >=20 > The early initialization goes like: >=20 > ... >=20 > /* Initialize and relocate ourselves. */ > assert(aux_info[AT_BASE] !=3D NULL); > init_rtld((caddr_t) aux_info[AT_BASE]->a_un.a_ptr, aux_info); >=20 > __progname =3D obj_rtld.path; > argv0 =3D argv[0] !=3D NULL ? argv[0] : "(null)"; > environ =3D env; >=20 > The init_rtld() function takes care of the initial relocations, after > which 'global' symbols like __progname and environ can be used. >=20 > However, at -O0, clang still reorders the retrieval of the __progname > offset to just *before* the init_rtld() call, and assigns it afterwards: >=20 > ... > .LBB0_16: # %cond.end > movq __progname@GOTPCREL(%rip), %rax <-- gets the offs= et=20 > here > leaq -224(%rbp), %rsi > .loc 1 329 5 #=20 > /usr/src/libexec/rtld-elf/rtld.c:329:5 > movq -168(%rbp), %rcx > movq 8(%rcx), %rdi > movq %rax, -1504(%rbp) # 8-byte Spill <-- saves offset = on=20 > stack > callq init_rtld > .loc 1 331 5 #=20 > /usr/src/libexec/rtld-elf/rtld.c:331:5 > movq obj_rtld+24(%rip), %rax > movq -1504(%rbp), %rcx # 8-byte Reload <-- loads offset= =20 > from stack > movq %rax, (%rcx) <-- stores value = in=20 > __progname >=20 > It's not clear to me why clang does this reordering even when > optimization is off, but it is normally legal, and quite usual. > However, in case of this early initialization, it is fatal, as > __progname@GOTPCREL(%rip) will still be junk, or zero... >=20 > With optimization, such reorderings are even more likely, but for some > reason, we have always been lucky that it turned out OK. A possible > solution would be to move the code after the init_rtld() call to another > function, and call that, but this could also be defeated again by > inlining. :( I think you can try to insert another compiler memory barrier after the init_rtld. > Index: libexec/rtld-elf/rtld.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- libexec/rtld-elf/rtld.c (revision 225105) > +++ libexec/rtld-elf/rtld.c (working copy) > @@ -143,7 +143,7 @@ static void ld_utrace_log(int, void *, void *, siz > static void rtld_fill_dl_phdr_info(const Obj_Entry *obj, > struct dl_phdr_info *phdr_info); > =20 > -void r_debug_state(struct r_debug *, struct link_map *); > +void r_debug_state(struct r_debug *, struct link_map *) __noinline; > =20 > /* > * Data declarations. > @@ -2780,6 +2780,14 @@ linkmap_delete(Obj_Entry *obj) > void > r_debug_state(struct r_debug* rd, struct link_map *m) > { > + /* > + * The following is a hack to force the compiler to emit calls to > + * this function, even when optimizing. If the function is empty, > + * the compiler is not obliged to emit any code for calls to it, > + * even when marked __noinline. However, gdb depends on those > + * calls being made. > + */ > + __asm __volatile("" : : : "memory"); > } This is a reasonable change, IMO. Also, we still compile rtld and csu in the hosted environment, which is the lie to the compiler. --g2QKYTO1/ZKqu+7N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk5Us8sACgkQC3+MBN1Mb4iohgCg9IrpApQtadl18L7riRr8wcOs DI0AoODMEBK9GHN6S0J6DF2Y9a95QeTQ =MpWV -----END PGP SIGNATURE----- --g2QKYTO1/ZKqu+7N--