From owner-freebsd-toolchain@FreeBSD.ORG Thu Apr 9 14:35:16 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57D74413 for ; Thu, 9 Apr 2015 14:35:16 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 38A34FC for ; Thu, 9 Apr 2015 14:35:16 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t39EZFqb060862 for ; Thu, 9 Apr 2015 14:35:15 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t39EZFt3060861; Thu, 9 Apr 2015 14:35:15 GMT (envelope-from root) Date: Thu, 9 Apr 2015 14:35:15 +0000 To: freebsd-toolchain@freebsd.org From: "emaste (Ed Maste)" Subject: [Differential] [Accepted] D1524: ar: Disallow directory traversal Message-ID: <492edee052a195f82d45948ac3c5cf6c@localhost.localdomain> X-Priority: 3 Thread-Topic: D1524: ar: Disallow directory traversal X-Herald-Rules: none X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Njc2MzUzYWFkN2I5MDZkNGU4MTcyOGJjZWU1IFUmjiM= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:35:16 -0000 emaste accepted this revision. emaste added a reviewer: emaste. This revision is now accepted and ready to land. REVISION DETAIL https://reviews.freebsd.org/D1524 To: emaste Cc: freebsd-toolchain From owner-freebsd-toolchain@FreeBSD.ORG Thu Apr 9 14:35:37 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC4F343E for ; Thu, 9 Apr 2015 14:35:37 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AE1B6105 for ; Thu, 9 Apr 2015 14:35:37 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t39EZbk3061138 for ; Thu, 9 Apr 2015 14:35:37 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t39EZbS5061137; Thu, 9 Apr 2015 14:35:37 GMT (envelope-from root) Date: Thu, 9 Apr 2015 14:35:37 +0000 To: freebsd-toolchain@freebsd.org From: "emaste (Ed Maste)" Subject: [Differential] [Closed] D1524: ar: Disallow directory traversal Message-ID: X-Priority: 3 Thread-Topic: D1524: ar: Disallow directory traversal X-Herald-Rules: none X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Njc2MzUzYWFkN2I5MDZkNGU4MTcyOGJjZWU1IFUmjjk= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:35:37 -0000 emaste closed this revision. emaste added a comment. Author: emaste Date: Thu Apr 9 13:45:17 2015 New Revision: 281311 URL: https://svnweb.freebsd.org/changeset/base/281311 REVISION DETAIL https://reviews.freebsd.org/D1524 To: emaste Cc: freebsd-toolchain From owner-freebsd-toolchain@FreeBSD.ORG Fri Apr 10 02:03:05 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58A7EEA3 for ; Fri, 10 Apr 2015 02:03:05 +0000 (UTC) Received: from asp.reflexion.net (outbound-243.asp.reflexion.net [69.84.129.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 010E3EEA for ; Fri, 10 Apr 2015 02:03:04 +0000 (UTC) Received: (qmail 16463 invoked from network); 10 Apr 2015 01:56:23 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 10 Apr 2015 01:56:23 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 09 Apr 2015 21:56:23 -0400 (EDT) Received: (qmail 16311 invoked from network); 10 Apr 2015 01:56:22 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Apr 2015 01:56:22 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id C07EA1C43A8; Thu, 9 Apr 2015 18:56:16 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Shorter version: -m elf32ppc_fbsd (and elf_i386_fbsd ?) vs. -Wl, -m, elf32ppc_fbsd problems (11.0-CURRENT and 10.1-STABLE) Date: Thu, 9 Apr 2015 18:56:21 -0700 Message-Id: <0D8F0A9A-593E-4FEE-8F01-20799DE946B2@dsl-only.net> To: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Cc: freebsd-ppc-owner@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 02:03:05 -0000 =46rom share/mk/bsd.README : LDFLAGS Additional loader flags. Passed to the loader via CC, since that's used to link programs as well, so loader specific flags need to be prefixed with -Wl, to work. But the following 3 powerpc (non-64) examples do not use the -Wl, = notation: > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/ofw/Makefile.inc > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/uboot/Makefile.inc > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/powerpc/Makefile.inc In fact I get errors such as (for that last one when using powerpc64-gcc = via powerpc64-xtoolchain-gcc, executed on a powerpc64): > powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file = or directory > powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file = or directory > powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' > powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >=20 > *** [boot1.elf] Error code 1 >=20 > make[6]: stopped in /usr/srcC/sys/boot/powerpc/boot1.chrp > 1 error I do not know if the space between -m and elf... creates a problem for = -Wl, use or not. I would guess that -Wl,-m,elf32pcc_fbsd is the proper notation for putting the space through to the ld variant = used. But I=E2=80=99m not to the point of testing the behavior of that = yet. i386 seems to have a similar example, although I=E2=80=99m not using = such a FreeBSD environment. > LD_FLAGS+=3D -m elf_i386_fbsd > /usr/src/sys/boot/i386/Makefile.inc (This note is shorter in part because figured out more context than I = had last time.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Fri Apr 10 02:35:49 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D002483 for ; Fri, 10 Apr 2015 02:35:49 +0000 (UTC) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED5DA25C for ; Fri, 10 Apr 2015 02:35:48 +0000 (UTC) Received: by pabsx10 with SMTP id sx10so6986436pab.3 for ; Thu, 09 Apr 2015 19:35:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=Z2ZE9I8kmmwPz370tYnJThZEvnHMhg9wHQ4KfGibFyI=; b=mr/3VpggMN5LbUUDGO+WwyRoKILnqDd6zDjRCYUMnO0j+r03B1p3gsTnIjWaNtuBA6 STtyb4MxCtxSO/e6UFeSHl5MTLHa20lSIvnPgKyeGGawgNvO4UVhnoL34aKdtx1b+PCA WKGSceDlXIKwzBUEc5ag7QSlWvOs3MAZA+0P62Fk8tDU4a8UpUGClgXCcw3Yb7cENDI3 K0x+uQYG3bnJbpgtvoP4wF2y0RF7LZzQnOheTnHb+OCD807QLdqnAA1CXwGktDkKH76H 2BZ89H5WrlXr/KWE3lFSOGNPXhAWYHNj+pF7bB3wu5fq27IBVeZbl6v1L6jTEDFMv0ds JFIQ== X-Gm-Message-State: ALoCoQnkB9ppanwENzm3SLJ+QaPAINH4a6cfRfxJ4alhog+2kFFMe+RmQYCllQdKvibTKUJ2kYfa X-Received: by 10.68.204.199 with SMTP id la7mr60821562pbc.147.1428633341868; Thu, 09 Apr 2015 19:35:41 -0700 (PDT) Received: from lgmac-pgupta.corp.netflix.com ([69.53.236.236]) by mx.google.com with ESMTPSA id n3sm384999pdm.90.2015.04.09.19.35.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Apr 2015 19:35:41 -0700 (PDT) Sender: Warner Losh Subject: Re: Shorter version: -m elf32ppc_fbsd (and elf_i386_fbsd ?) vs. -Wl, -m, elf32ppc_fbsd problems (11.0-CURRENT and 10.1-STABLE) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1810AE61-2B69-432B-AADF-83D8267DB323"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Warner Losh In-Reply-To: <0D8F0A9A-593E-4FEE-8F01-20799DE946B2@dsl-only.net> Date: Thu, 9 Apr 2015 20:35:44 -0600 Message-Id: References: <0D8F0A9A-593E-4FEE-8F01-20799DE946B2@dsl-only.net> To: Mark Millard X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ppc-owner@freebsd.org, freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 02:35:49 -0000 --Apple-Mail=_1810AE61-2B69-432B-AADF-83D8267DB323 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 9, 2015, at 7:56 PM, Mark Millard wrote: >=20 > =46rom share/mk/bsd.README : >=20 > LDFLAGS Additional loader flags. Passed to the loader via CC, > since that's used to link programs as well, so loader > specific flags need to be prefixed with -Wl, to work. >=20 > But the following 3 powerpc (non-64) examples do not use the -Wl, = notation: >=20 >> LDFLAGS+=3D -m elf32ppc_fbsd >> /usr/src/sys/boot/ofw/Makefile.inc >=20 >=20 >> LDFLAGS+=3D -m elf32ppc_fbsd >> /usr/src/sys/boot/uboot/Makefile.inc >=20 >=20 >> LDFLAGS+=3D -m elf32ppc_fbsd >> /usr/src/sys/boot/powerpc/Makefile.inc >=20 > In fact I get errors such as (for that last one when using = powerpc64-gcc via powerpc64-xtoolchain-gcc, executed on a powerpc64): >=20 >> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file = or directory >> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file = or directory >> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >>=20 >> *** [boot1.elf] Error code 1 >>=20 >> make[6]: stopped in /usr/srcC/sys/boot/powerpc/boot1.chrp >> 1 error >=20 > I do not know if the space between -m and elf... creates a problem for = -Wl, use or not. I would guess that >=20 > -Wl,-m,elf32pcc_fbsd >=20 > is the proper notation for putting the space through to the ld variant = used. But I=E2=80=99m not to the point of testing the behavior of that = yet. >=20 >=20 >=20 > i386 seems to have a similar example, although I=E2=80=99m not using = such a FreeBSD environment. >=20 >> LD_FLAGS+=3D -m elf_i386_fbsd >> /usr/src/sys/boot/i386/Makefile.inc >=20 >=20 >=20 > (This note is shorter in part because figured out more context than I = had last time.) I think much of this is historical accident where the boot Makefiles = used to call ld directly, then were converted to call gcc, and gcc = allowed the -m notation like this as a historical compatibility. Do thinks still work if you use -Wl, notation? Warner --Apple-Mail=_1810AE61-2B69-432B-AADF-83D8267DB323 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVJzcBAAoJEGwc0Sh9sBEAB48P/1WVoGrkzD/Mhc2uHxc6uTR/ mJkNXIigB1rh9U/aqqzibY5hQKR2v/9BUCwC+oLEO5MsdJU6wI/y+dRx0ejuBz9L 2hT8ilOXEgnrUxM9ycEXBh47AOrTrIPk/LtjmBLkke+RqCfyH5AqeM6cTdRJ2FVc qGEOL/SD53kOwUPRnUhcC5DytHmvuFUaOibP+8eKUfzt22J34C9NWuDehdOWYt/F sTw/v84+oXDTZLkW5ZaF+RLH1BfeP2ed9M5NY8VES/TpL++jfejcFHgTA84d8hAu LrgDpHKlC10+Z0rqEvtoX5wX0b4mh7kCHQdXLIs2xRL381xhWlTuWaBID4c70/+r 7yTTn0fQ2JAYf/mFV4LoW54W6T/6Oo4gC9HNohzpX6MjQBJuc2r69uVqMUoskgSj CdDzPKuXXPsK1+ce8m6S+oQojgy7fXmrS6u+9e6AeTRsLaA0fNoUL0RKxSuE1wiz zEDhdtScPqKarLA0oy/8K/MGbyA7v4vgedUDzAUXGuG71pd4WCzXObEQEgRrwasz aScyTQ8rK+7N0yeUDO6HBhPQA02QufUy/BOVU3m8DAMlGf98jq2emN7mQMcY/vZS e5n8usZ+0kFDS5TViGLkV1DlXo3+Daq3w/rFyi/X0pW+3hiOc4kJWgcyDlU6QfWw UJ0K7jvHjk+4VhVgw00i =ixYJ -----END PGP SIGNATURE----- --Apple-Mail=_1810AE61-2B69-432B-AADF-83D8267DB323-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Apr 10 02:40:04 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC49252D for ; Fri, 10 Apr 2015 02:40:04 +0000 (UTC) Received: from asp.reflexion.net (outbound-243.asp.reflexion.net [69.84.129.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 62A55286 for ; Fri, 10 Apr 2015 02:40:03 +0000 (UTC) Received: (qmail 4719 invoked from network); 10 Apr 2015 02:40:02 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 10 Apr 2015 02:40:02 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 09 Apr 2015 22:40:02 -0400 (EDT) Received: (qmail 24503 invoked from network); 10 Apr 2015 02:40:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Apr 2015 02:40:01 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 906971C4052; Thu, 9 Apr 2015 19:39:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: Shorter version: -m elf32ppc_fbsd (and elf_i386_fbsd ?) vs. -Wl, -m, elf32ppc_fbsd problems (11.0-CURRENT and 10.1-STABLE) From: Mark Millard In-Reply-To: <0D8F0A9A-593E-4FEE-8F01-20799DE946B2@dsl-only.net> Date: Thu, 9 Apr 2015 19:40:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D8F0A9A-593E-4FEE-8F01-20799DE946B2@dsl-only.net> To: freebsd-toolchain@freebsd.org X-Mailer: Apple Mail (2.2098) Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 02:40:04 -0000 I now see one place where "-Wl,-m,elf32ppc_fbsd" type of notation in = LDFLAGS would not be handled if it ended up involved: share/mk/sys.mk:_LDFLAGS =3D ${LDFLAGS:S/-Wl,//g} # = strip -Wl, for LD This notation does not deal with turning the extra comma back into a = space. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Apr-9, at 06:56 PM, Mark Millard wrote: =46rom share/mk/bsd.README : LDFLAGS Additional loader flags. Passed to the loader via CC, since that's used to link programs as well, so loader specific flags need to be prefixed with -Wl, to work. But the following 3 powerpc (non-64) examples do not use the -Wl, = notation: > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/ofw/Makefile.inc > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/uboot/Makefile.inc > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/powerpc/Makefile.inc In fact I get errors such as (for that last one when using powerpc64-gcc = via powerpc64-xtoolchain-gcc, executed on a powerpc64): > powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file = or directory > powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file = or directory > powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' > powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >=20 > *** [boot1.elf] Error code 1 >=20 > make[6]: stopped in /usr/srcC/sys/boot/powerpc/boot1.chrp > 1 error I do not know if the space between -m and elf... creates a problem for = -Wl, use or not. I would guess that -Wl,-m,elf32pcc_fbsd is the proper notation for putting the space through to the ld variant = used. But I=E2=80=99m not to the point of testing the behavior of that = yet. i386 seems to have a similar example, although I=E2=80=99m not using = such a FreeBSD environment. > LD_FLAGS+=3D -m elf_i386_fbsd > /usr/src/sys/boot/i386/Makefile.inc (This note is shorter in part because figured out more context than I = had last time.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Fri Apr 10 02:48:13 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D73446E4 for ; Fri, 10 Apr 2015 02:48:13 +0000 (UTC) Received: from asp.reflexion.net (outbound-243.asp.reflexion.net [69.84.129.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7B470393 for ; Fri, 10 Apr 2015 02:48:13 +0000 (UTC) Received: (qmail 16223 invoked from network); 10 Apr 2015 02:48:12 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 10 Apr 2015 02:48:12 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 09 Apr 2015 22:48:12 -0400 (EDT) Received: (qmail 1897 invoked from network); 10 Apr 2015 02:48:11 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Apr 2015 02:48:11 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 90E151C4052; Thu, 9 Apr 2015 19:48:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: Shorter version: -m elf32ppc_fbsd (and elf_i386_fbsd ?) vs. -Wl, -m, elf32ppc_fbsd problems (11.0-CURRENT and 10.1-STABLE) From: Mark Millard In-Reply-To: Date: Thu, 9 Apr 2015 19:48:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7049E178-9FC8-4590-95AD-F80A2BBC3F01@dsl-only.net> References: <0D8F0A9A-593E-4FEE-8F01-20799DE946B2@dsl-only.net> To: Warner Losh X-Mailer: Apple Mail (2.2098) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 02:48:14 -0000 On 2015-Apr-9, at 07:35 PM, Warner Losh wrote: >=20 >> On Apr 9, 2015, at 7:56 PM, Mark Millard wrote: >>=20 >> =46rom share/mk/bsd.README : >>=20 >> LDFLAGS Additional loader flags. Passed to the loader via CC, >> since that's used to link programs as well, so loader >> specific flags need to be prefixed with -Wl, to work. >>=20 >> But the following 3 powerpc (non-64) examples do not use the -Wl, = notation: >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/ofw/Makefile.inc >>=20 >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/uboot/Makefile.inc >>=20 >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/powerpc/Makefile.inc >>=20 >> In fact I get errors such as (for that last one when using = powerpc64-gcc via powerpc64-xtoolchain-gcc, executed on a powerpc64): >>=20 >>> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such = file or directory >>> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such = file or directory >>> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >>> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >>>=20 >>> *** [boot1.elf] Error code 1 >>>=20 >>> make[6]: stopped in /usr/srcC/sys/boot/powerpc/boot1.chrp >>> 1 error >>=20 >> I do not know if the space between -m and elf... creates a problem = for -Wl, use or not. I would guess that >>=20 >> -Wl,-m,elf32pcc_fbsd >>=20 >> is the proper notation for putting the space through to the ld = variant used. But I=E2=80=99m not to the point of testing the behavior = of that yet. >>=20 >>=20 >>=20 >> i386 seems to have a similar example, although I=E2=80=99m not using = such a FreeBSD environment. >>=20 >>> LD_FLAGS+=3D -m elf_i386_fbsd >>> /usr/src/sys/boot/i386/Makefile.inc >>=20 >>=20 >>=20 >> (This note is shorter in part because figured out more context than I = had last time.) >=20 > I think much of this is historical accident where the boot Makefiles = used to call ld directly, then were converted to call gcc, and gcc = allowed the -m notation like this as a historical compatibility. >=20 > Do thinks still work if you use -Wl, notation? >=20 > Warner >=20 I have a powerpc64-xtoolchain-gcc build going now but that will take a = while. I=E2=80=99ll also need to try a normal one from a gcc 4.2.1 = environment and I=E2=80=99ve not started that yet. And I=E2=80=99m only = set up to test powerpc64 and powerpc. The tier 1 consequences (i386 and = amd64) are outside my environment. Also I sent out another note after discovering a potential problem... > I now see one place where "-Wl,-m,elf32ppc_fbsd" type of notation in = LDFLAGS would not be handled if it ended up involved: >=20 > share/mk/sys.mk:_LDFLAGS =3D ${LDFLAGS:S/-Wl,//g} # = strip -Wl, for LD >=20 > This notation does not deal with turning the extra comma back into a = space. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Fri Apr 10 03:46:52 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38DB6EE3 for ; Fri, 10 Apr 2015 03:46:52 +0000 (UTC) Received: from asp.reflexion.net (outbound-243.asp.reflexion.net [69.84.129.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E504BC83 for ; Fri, 10 Apr 2015 03:46:51 +0000 (UTC) Received: (qmail 11016 invoked from network); 10 Apr 2015 03:46:50 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 10 Apr 2015 03:46:50 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 09 Apr 2015 23:46:50 -0400 (EDT) Received: (qmail 32291 invoked from network); 10 Apr 2015 03:46:49 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Apr 2015 03:46:49 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 204641C4052; Thu, 9 Apr 2015 20:46:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: Shorter version: -m elf32ppc_fbsd (and elf_i386_fbsd ?) vs. -Wl, -m, elf32ppc_fbsd problems (11.0-CURRENT and 10.1-STABLE) From: Mark Millard In-Reply-To: <7049E178-9FC8-4590-95AD-F80A2BBC3F01@dsl-only.net> Date: Thu, 9 Apr 2015 20:46:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D8F0A9A-593E-4FEE-8F01-20799DE946B2@dsl-only.net> <7049E178-9FC8-4590-95AD-F80A2BBC3F01@dsl-only.net> To: Warner Losh X-Mailer: Apple Mail (2.2098) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 03:46:52 -0000 I had written: > I now see one place where "-Wl,-m,elf32ppc_fbsd" type of notation in = LDFLAGS would not be handled if it ended up involved: >=20 > share/mk/sys.mk:_LDFLAGS =3D ${LDFLAGS:S/-Wl,//g} # = strip -Wl, for LD >=20 > This notation does not deal with turning the extra comma back into a = space. So I=E2=80=99ve restarted the powerpc64 FreeBSD hosted tests, now based = on the notation -Wl,-m -Wl,elf32ppc_fbsd which sys.mk=E2=80=99s _LDFLAGS assignment should handle okay. One test is building 11.0-CURRENT -r281236 via powerpc64-xtoolchain-gcc = and the other is building 10.1-STABLE -r281235 via the system/normal gcc = 4.2.1. As my builds take considerable time if they actually complete, it will = be a while before I can try any other variations, such as trying a gcc = 4.2.1 cross-build for powerpc. Unfortunately for the purpose at hand: I=E2=80=99m not set up to test = any tier 1 FreeBSD environments at this time. So, for example, I can not = report observations for amd64 building elf_i386_fbsd materials. My tests = may be useful but are not sufficient of themselves to justify edits that = anyone worries might damage tier 1 build-ability. The places I found with notation to adjust if in general the updated = notation works are: > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/ofw/Makefile.inc > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/uboot/Makefile.inc > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/powerpc/Makefile.inc and the tier 1 case using elf_i386_fbsd: > LD_FLAGS+=3D -m elf_i386_fbsd > /usr/src/sys/boot/i386/Makefile.inc =3D=3D=3D Mark Millard markmi at dsl-only.net Just for reference=E2=80=A6 On 2015-Apr-9, at 07:35 PM, Warner Losh wrote: >=20 >> On Apr 9, 2015, at 7:56 PM, Mark Millard wrote: >>=20 >> =46rom share/mk/bsd.README : >>=20 >> LDFLAGS Additional loader flags. Passed to the loader via CC, >> since that's used to link programs as well, so loader >> specific flags need to be prefixed with -Wl, to work. >>=20 >> But the following 3 powerpc (non-64) examples do not use the -Wl, = notation: >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/ofw/Makefile.inc >>=20 >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/uboot/Makefile.inc >>=20 >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/powerpc/Makefile.inc >>=20 >> In fact I get errors such as (for that last one when using = powerpc64-gcc via powerpc64-xtoolchain-gcc, executed on a powerpc64): >>=20 >>> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such = file or directory >>> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such = file or directory >>> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >>> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >>>=20 >>> *** [boot1.elf] Error code 1 >>>=20 >>> make[6]: stopped in /usr/srcC/sys/boot/powerpc/boot1.chrp >>> 1 error >>=20 >> I do not know if the space between -m and elf... creates a problem = for -Wl, use or not. I would guess that >>=20 >> -Wl,-m,elf32pcc_fbsd >>=20 >> is the proper notation for putting the space through to the ld = variant used. But I=E2=80=99m not to the point of testing the behavior = of that yet. >>=20 >>=20 >>=20 >> i386 seems to have a similar example, although I=E2=80=99m not using = such a FreeBSD environment. >>=20 >>> LD_FLAGS+=3D -m elf_i386_fbsd >>> /usr/src/sys/boot/i386/Makefile.inc >>=20 >>=20 >>=20 >> (This note is shorter in part because figured out more context than I = had last time.) >=20 > I think much of this is historical accident where the boot Makefiles = used to call ld directly, then were converted to call gcc, and gcc = allowed the -m notation like this as a historical compatibility. >=20 > Do thinks still work if you use -Wl, notation? >=20 > Warner >=20 I have a powerpc64-xtoolchain-gcc build going now but that will take a = while. I=E2=80=99ll also need to try a normal one from a gcc 4.2.1 = environment and I=E2=80=99ve not started that yet. And I=E2=80=99m only = set up to test powerpc64 and powerpc. The tier 1 consequences (i386 and = amd64) are outside my environment. Also I sent out another note after discovering a potential problem... > I now see one place where "-Wl,-m,elf32ppc_fbsd" type of notation in = LDFLAGS would not be handled if it ended up involved: >=20 > share/mk/sys.mk:_LDFLAGS =3D ${LDFLAGS:S/-Wl,//g} # = strip -Wl, for LD >=20 > This notation does not deal with turning the extra comma back into a = space. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Fri Apr 10 04:40:15 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C11D56E1 for ; Fri, 10 Apr 2015 04:40:15 +0000 (UTC) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C17617A for ; Fri, 10 Apr 2015 04:40:15 +0000 (UTC) Received: by pdea3 with SMTP id a3so10251135pde.3 for ; Thu, 09 Apr 2015 21:40:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=kAM0sCXjUVOdGgLwZamN3s6M2ANFZIzJfdfuk5tJA0A=; b=lv7/TbzYG3uUhWawgnBTL084l31YW216qAJ92P8WK8Um2sStlvGBOPh++spV3zyCFR hupEITuZxhBGNIce7ENc69/9lIKXrsbQJPMxDO9KDFc0SL6iDElg/gFySAL5GTtTCsoH LBSwNRoNlWQMXwyciwEcOl/W8KTS83QfFD1HWYcVBR+cc0i6J4/WFrOfM+8Gs1ACI/V0 KT3C5KL2nrMuyr3I7GgV7YfOUol05ZKKIV1oHDLmqjrJf+7RXzEO8V7qEAqcaOCBIjV0 v9wRV01WD3NFTnjQFlBxP3Xp8D5Ve8dQQ7ReQ2uywtjBz/oNc2jE0O9niEd3oanyulnT whWw== X-Gm-Message-State: ALoCoQkQBcTLRKJcf2NWX2gWwTsS1qi4n0yyX+qpAXZ5M5XnqbidnzcfvdQ1AN3SKG9QCVIy6Krq X-Received: by 10.70.89.237 with SMTP id br13mr62300876pdb.135.1428640809364; Thu, 09 Apr 2015 21:40:09 -0700 (PDT) Received: from lgmac-pgupta.corp.netflix.com ([69.53.236.236]) by mx.google.com with ESMTPSA id fc3sm670523pdb.22.2015.04.09.21.40.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Apr 2015 21:40:08 -0700 (PDT) Sender: Warner Losh Subject: Re: Shorter version: -m elf32ppc_fbsd (and elf_i386_fbsd ?) vs. -Wl, -m, elf32ppc_fbsd problems (11.0-CURRENT and 10.1-STABLE) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_2AF758D6-16F2-4888-903E-6DCE65385A8C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Warner Losh In-Reply-To: Date: Thu, 9 Apr 2015 22:40:12 -0600 Message-Id: <95515F28-A077-4245-90CC-85235C58CAC5@bsdimp.com> References: <0D8F0A9A-593E-4FEE-8F01-20799DE946B2@dsl-only.net> To: Mark Millard X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 04:40:15 -0000 --Apple-Mail=_2AF758D6-16F2-4888-903E-6DCE65385A8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 9, 2015, at 8:40 PM, Mark Millard wrote: >=20 > I now see one place where "-Wl,-m,elf32ppc_fbsd" type of notation in = LDFLAGS would not be handled if it ended up involved: >=20 > share/mk/sys.mk:_LDFLAGS =3D ${LDFLAGS:S/-Wl,//g} # = strip -Wl, for LD >=20 > This notation does not deal with turning the extra comma back into a = space. It should be "-Wl,-m -Wl,elf32ppc_fbsd=E2=80=9D since that=E2=80=99s the = same, isn=E2=80=99t it? That=E2=80=99s what it will do. And that=E2=80=99s= correct. Warner > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2015-Apr-9, at 06:56 PM, Mark Millard = wrote: >=20 > =46rom share/mk/bsd.README : >=20 > LDFLAGS Additional loader flags. Passed to the loader via CC, > since that's used to link programs as well, so loader > specific flags need to be prefixed with -Wl, to work. >=20 > But the following 3 powerpc (non-64) examples do not use the -Wl, = notation: >=20 >> LDFLAGS+=3D -m elf32ppc_fbsd >> /usr/src/sys/boot/ofw/Makefile.inc >=20 >=20 >> LDFLAGS+=3D -m elf32ppc_fbsd >> /usr/src/sys/boot/uboot/Makefile.inc >=20 >=20 >> LDFLAGS+=3D -m elf32ppc_fbsd >> /usr/src/sys/boot/powerpc/Makefile.inc >=20 > In fact I get errors such as (for that last one when using = powerpc64-gcc via powerpc64-xtoolchain-gcc, executed on a powerpc64): >=20 >> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file = or directory >> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file = or directory >> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >>=20 >> *** [boot1.elf] Error code 1 >>=20 >> make[6]: stopped in /usr/srcC/sys/boot/powerpc/boot1.chrp >> 1 error >=20 > I do not know if the space between -m and elf... creates a problem for = -Wl, use or not. I would guess that >=20 > -Wl,-m,elf32pcc_fbsd >=20 > is the proper notation for putting the space through to the ld variant = used. But I=E2=80=99m not to the point of testing the behavior of that = yet. >=20 >=20 >=20 > i386 seems to have a similar example, although I=E2=80=99m not using = such a FreeBSD environment. >=20 >> LD_FLAGS+=3D -m elf_i386_fbsd >> /usr/src/sys/boot/i386/Makefile.inc >=20 >=20 >=20 > (This note is shorter in part because figured out more context than I = had last time.) >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" --Apple-Mail=_2AF758D6-16F2-4888-903E-6DCE65385A8C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVJ1QsAAoJEGwc0Sh9sBEA6LIQAI4XnfOpjioNjyTeAmxllbtu Qfpe2O7n61lD/HzmC7CRQKoHsJyMfjfbBFVV312lOh3tL0cL6arsMyv7WSFQsCFE 7ZXKhjmRAAe/qtviHawg8nIl8N5vu1So56k+zRcJYHlb3x/5iKkAaqwvp85lt0+r Sg2IuQ5rxsTKV3NPR5M0FKrPVklak9s9MMpglell0ZmoU2AysGNiCvFV8lrK8w1p 2lKYdnCmiHhFCRp8Jd8pENQiBv5fKTLykj+z0lKgr6nJbt8qm+QiP6K4ogGv68kj OURz6bcNvRt597UCuUrH9AQ/gbX0zwAM0AjvMPlZnBNMVZDSKIGsnFjw4BUn04pq AcZwTKxCqvJn+pdkvH9rDefx+/RyLzpb68FZoIxZPU87CDilpCno8ALqf+ZnsRQM xXrqDqeqY6n5g7EUhavAfxK7UL/+rAwxxLuVgemdhYptRS/3moUhLfZzWLgqqk5V Yfr9I+6LkDLPtABNgnBppp73B8CUh5feYMbaUi6XmsAlRdvUpp622IWvI1mRAHOS DXjINS68cmwnTajC2fmoCH4L8kyEw3RmXTMfKIs/XkxDKtfYN6z5Vo394dN8EZUU 2NumwO4bis4x8FKUZisSdWuyvZfoboY66C4Uc7swLk6P56wpeluuhaSjuVJaLB/T 0F17NG2b0c4kvQrAr4Z3 =hqHK -----END PGP SIGNATURE----- --Apple-Mail=_2AF758D6-16F2-4888-903E-6DCE65385A8C-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Apr 10 16:13:47 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42DC627C for ; Fri, 10 Apr 2015 16:13:47 +0000 (UTC) Received: from nm47-vm6.bullet.mail.bf1.yahoo.com (nm47-vm6.bullet.mail.bf1.yahoo.com [216.109.115.141]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E1DBDECC for ; Fri, 10 Apr 2015 16:13:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1428682294; bh=BVaUxACt7znPvtqpGR46JmiE742nW8IuoMaCbwQP23w=; h=Date:From:To:Subject:From:Subject; b=svizQtq4vEFRPaUlf34loKKWdiPxsJ/2Yy1HivjpXA331srMlLdVNcT6cqHhcAg8hA/Oo59c7y3FiK5fCT4TtHVkgeoK4Fp65q8jNYbZXdU58BqNXfBqX60zrU3Bya1a2nN67Zoew16PFKtPgveoIebi6a4r03qpwrSHB9x1R22ssrDuQvYbHUVEjktDiWeIzqhKqX5WnHr9MR1TrJ7EjUkkPnf3j9W9eesCsR1PjTgpggehcFqTtOTq9VDksc7uvb+GDJfVwgPYifnX3RULCmEKHJezG3nI6VvbhxubL29Y/P58cPt/mE0Fc8zGVlPZOqUCUoQ4eFrkxVuLBLNTuQ== Received: from [98.139.215.142] by nm47.bullet.mail.bf1.yahoo.com with NNFMP; 10 Apr 2015 16:11:34 -0000 Received: from [68.142.230.65] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 10 Apr 2015 16:11:34 -0000 Received: from [127.0.0.1] by smtp222.mail.bf1.yahoo.com with NNFMP; 10 Apr 2015 16:11:34 -0000 X-Yahoo-Newman-Id: 214180.16519.bm@smtp222.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: gTjA.sgVM1n4LXcFIMwO17OdSvKyWyD9y3J0IwwmjzINUB8 UqLp0DouQ3_ht90sbQsvJSCBSwx7YPDBkrhDQn.d8lw.cr4I_6YEmtjgS3kO UmZVs0Km1mJKauHxTrkUnhFGJD9lQkCiz_0U39591KZkPyG6ePPtW962lZmS SKWJogTqdasjHHXIIBeoC2lzHZiX4ICs0AML6WknaQdIJ._Io.1dC8f0KiJa EG7OmZtr0ONpuX_UKus7JXVkGzffHLp67cH3Ks7YlVgihsh5Bim3lT5ZhSI1 Eifdc36q.Gr7EYSYC5NnkqYYZ_ZY5LSclRB6SNzrcFgtOKx3cG0h9_YI7hxm o82AT_fmPsQ1bN9gDSpvLdUg7uI9.VGHyjittQDzdsSSAkxvTfRZMlBE4rkk .OM6rd8T1QFTmXEQAT2DNQaCvh4b3q.Q40uDgv1M8NxAk__JdFQ5SU81Hxdf a28oYZpDrcZR7nllpyVdGUkdH1W_azaZ72YwDwL5XN7i9JToZBo2twemwyvv KGx_AjqT5xYKborOxzShDIZFmdthYU_e8 X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Message-ID: <5527F638.9090609@FreeBSD.org> Date: Fri, 10 Apr 2015 11:11:36 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-toolchain@FreeBSD.org Subject: type-safety checks for fcntl and ioctl Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 16:13:47 -0000 Hello; I had a try on adding the ioctl() and fcntl() clang attributes to our system headers but failed miserably, apparently due to xlint issues: ... fcntl.h(307): syntax error [249] ... There is few documentation about this [1][2] so I am sharing the link of my (simple but probably incomplete) experiment in case someone feels like picking it up some day: https://people.freebsd.org/~pfg/patches/fcntl-type-safety.diff Regards, Pedro. References: [1] http://clang.llvm.org/docs/AttributeReference.html#type-safety-checking [2] http://hpc-ua.org/hpc-ua-12/files/proceedings/3.pdf From owner-freebsd-toolchain@FreeBSD.ORG Fri Apr 10 21:21:20 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2AE29318 for ; Fri, 10 Apr 2015 21:21:20 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D3CF197D for ; Fri, 10 Apr 2015 21:21:19 +0000 (UTC) Received: (qmail 27593 invoked from network); 10 Apr 2015 21:21:18 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 10 Apr 2015 21:21:18 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Fri, 10 Apr 2015 17:21:18 -0400 (EDT) Received: (qmail 1659 invoked from network); 10 Apr 2015 21:21:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Apr 2015 21:21:18 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 6F3BDB1E001; Fri, 10 Apr 2015 14:21:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: Shorter version: -m elf32ppc_fbsd (and elf_i386_fbsd ?) vs. -Wl, -m, elf32ppc_fbsd problems (11.0-CURRENT and 10.1-STABLE) From: Mark Millard In-Reply-To: Date: Fri, 10 Apr 2015 14:21:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D8F0A9A-593E-4FEE-8F01-20799DE946B2@dsl-only.net> <7049E178-9FC8-4590-95AD-F80A2BBC3F01@dsl-only.net> To: Warner Losh X-Mailer: Apple Mail (2.2098) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 21:21:20 -0000 I had written: > So I=E2=80=99ve restarted the powerpc64 FreeBSD hosted tests, now = based on the notation >=20 > -Wl,-m -Wl,elf32ppc_fbsd >=20 > which sys.mk=E2=80=99s _LDFLAGS assignment should handle okay. Based on the system/normal gcc 4.2.1 context I=E2=80=99ve successfully = updated/rebuilt/booted: A) powerpc64 10.1-STABLE -r281235 (self updated from my prior snapshot) B) powerpc64 11.0-CURRENT -r281236 C) powerpc 11.0-CURRENT -r281236 (with -r281243 applied to fix register = save/restore) (B) and (C) were built from (A)=E2=80=99s context (using a separate = 11.0-CURRENT svn-based source tree) and DESTDIR used to installkernel = and installworld to other SSD=E2=80=99s that were being updated. The powerpc64-xtoolchain-gcc experimental update on a different PowerMac = G5 G5 did okay as far as it got based on the notation. But it did not = complete. It will be a while before I research the following references = to compiler support routines for restoring various general purpose = registers. > /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -ffreestanding = -msoft-float -Os -I/usr/src/sys/boot/powerpc/boot1.chrp/../../common = -I/usr/src/sys/boot/powerpc/boot1.chrp/../../../ -D_STANDALONE -m > 32 -mcpu=3Dpowerpc -m32 -mcpu=3Dpowerpc -std=3Dgnu99 -nostdlib = -static -Wl,-N -Wl,-m -Wl,elf32ppc_fbsd -Wl,-m -Wl,elf32ppc_fbsd -o = boot1.elf boot1.o ashldi3.o syncicache.o=20 got: > boot1.o: In function `__puts': > boot1.c:(.text+0xf4): undefined reference to `_restgpr_28_x' > boot1.o: In function `__printf': > boot1.c:(.text+0x4fc): undefined reference to `_restgpr_24_x' > boot1.o: In function `ofw_getprop': > boot1.c:(.text+0x628): undefined reference to `_restgpr_31_x' > boot1.o: In function `ofw_close': > boot1.c:(.text+0x694): undefined reference to `_restgpr_31_x' > boot1.o: In function `dskread': > boot1.c:(.text+0x79c): undefined reference to `_restgpr_25_x' > boot1.o: In function `fsread': > boot1.c:(.text+0xce4): undefined reference to `_restgpr_14_x' > boot1.o: In function `domount': > boot1.c:(.text+0xdb8): undefined reference to `_restgpr_28_x' > boot1.o: In function `ofw_write.constprop.2': > boot1.c:(.text+0xe40): undefined reference to `_restgpr_30_x' > boot1.o: In function `putchar': > boot1.c:(.text+0xe90): undefined reference to `_restgpr_30_x' > boot1.o: In function `main': > boot1.c:(.text.startup+0x528): undefined reference to `_restgpr_18_x' > collect2: error: ld returned 1 exit status > *** [boot1.elf] Error code 1 Before the -Wl, notation changes I did not get this far so -WL,-m = -Wl,elf32ppc_fbsd did help. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Apr-9, at 08:46 PM, Mark Millard wrote: I had written: > I now see one place where "-Wl,-m,elf32ppc_fbsd" type of notation in = LDFLAGS would not be handled if it ended up involved: >=20 > share/mk/sys.mk:_LDFLAGS =3D ${LDFLAGS:S/-Wl,//g} # = strip -Wl, for LD >=20 > This notation does not deal with turning the extra comma back into a = space. So I=E2=80=99ve restarted the powerpc64 FreeBSD hosted tests, now based = on the notation -Wl,-m -Wl,elf32ppc_fbsd which sys.mk=E2=80=99s _LDFLAGS assignment should handle okay. One test is building 11.0-CURRENT -r281236 via powerpc64-xtoolchain-gcc = and the other is building 10.1-STABLE -r281235 via the system/normal gcc = 4.2.1. As my builds take considerable time if they actually complete, it will = be a while before I can try any other variations, such as trying a gcc = 4.2.1 cross-build for powerpc. Unfortunately for the purpose at hand: I=E2=80=99m not set up to test = any tier 1 FreeBSD environments at this time. So, for example, I can not = report observations for amd64 building elf_i386_fbsd materials. My tests = may be useful but are not sufficient of themselves to justify edits that = anyone worries might damage tier 1 build-ability. The places I found with notation to adjust if in general the updated = notation works are: > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/ofw/Makefile.inc > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/uboot/Makefile.inc > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/powerpc/Makefile.inc and the tier 1 case using elf_i386_fbsd: > LD_FLAGS+=3D -m elf_i386_fbsd > /usr/src/sys/boot/i386/Makefile.inc =3D=3D=3D Mark Millard markmi at dsl-only.net Just for reference=E2=80=A6 On 2015-Apr-9, at 07:35 PM, Warner Losh wrote: >=20 >> On Apr 9, 2015, at 7:56 PM, Mark Millard wrote: >>=20 >> =46rom share/mk/bsd.README : >>=20 >> LDFLAGS Additional loader flags. Passed to the loader via CC, >> since that's used to link programs as well, so loader >> specific flags need to be prefixed with -Wl, to work. >>=20 >> But the following 3 powerpc (non-64) examples do not use the -Wl, = notation: >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/ofw/Makefile.inc >>=20 >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/uboot/Makefile.inc >>=20 >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/powerpc/Makefile.inc >>=20 >> In fact I get errors such as (for that last one when using = powerpc64-gcc via powerpc64-xtoolchain-gcc, executed on a powerpc64): >>=20 >>> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such = file or directory >>> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such = file or directory >>> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >>> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >>>=20 >>> *** [boot1.elf] Error code 1 >>>=20 >>> make[6]: stopped in /usr/srcC/sys/boot/powerpc/boot1.chrp >>> 1 error >>=20 >> I do not know if the space between -m and elf... creates a problem = for -Wl, use or not. I would guess that >>=20 >> -Wl,-m,elf32pcc_fbsd >>=20 >> is the proper notation for putting the space through to the ld = variant used. But I=E2=80=99m not to the point of testing the behavior = of that yet. >>=20 >>=20 >>=20 >> i386 seems to have a similar example, although I=E2=80=99m not using = such a FreeBSD environment. >>=20 >>> LD_FLAGS+=3D -m elf_i386_fbsd >>> /usr/src/sys/boot/i386/Makefile.inc >>=20 >>=20 >>=20 >> (This note is shorter in part because figured out more context than I = had last time.) >=20 > I think much of this is historical accident where the boot Makefiles = used to call ld directly, then were converted to call gcc, and gcc = allowed the -m notation like this as a historical compatibility. >=20 > Do thinks still work if you use -Wl, notation? >=20 > Warner >=20 I have a powerpc64-xtoolchain-gcc build going now but that will take a = while. I=E2=80=99ll also need to try a normal one from a gcc 4.2.1 = environment and I=E2=80=99ve not started that yet. And I=E2=80=99m only = set up to test powerpc64 and powerpc. The tier 1 consequences (i386 and = amd64) are outside my environment. Also I sent out another note after discovering a potential problem... > I now see one place where "-Wl,-m,elf32ppc_fbsd" type of notation in = LDFLAGS would not be handled if it ended up involved: >=20 > share/mk/sys.mk:_LDFLAGS =3D ${LDFLAGS:S/-Wl,//g} # = strip -Wl, for LD >=20 > This notation does not deal with turning the extra comma back into a = space. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Sat Apr 11 03:17:18 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF036D3B for ; Sat, 11 Apr 2015 03:17:17 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 856F3F88 for ; Sat, 11 Apr 2015 03:17:16 +0000 (UTC) Received: (qmail 26066 invoked from network); 11 Apr 2015 03:17:15 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 11 Apr 2015 03:17:15 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Fri, 10 Apr 2015 23:17:15 -0400 (EDT) Received: (qmail 17364 invoked from network); 11 Apr 2015 03:17:15 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Apr 2015 03:17:15 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id A9E741C43AF; Fri, 10 Apr 2015 20:17:08 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerc64-xtoolchain-gcc with -m32 on powerpc64 vs. lib32/libedit and wchar_t use: gcc 4.9.1 forces __WCHAR_TYPE__ (underlying type?) long int Date: Fri, 10 Apr 2015 20:17:13 -0700 Message-Id: <5B228278-A967-46D4-8F56-08E47008D009@dsl-only.net> To: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 03:17:18 -0000 I got the following when trying WITH_LIB32=3D with = powerpc64-xtoolchain-gcc (on a powerpc64 box, WITHOUT_BOOT=3D ) : > . . . parse.c:181:25: error: array of inappropriate type initialized = from string constant > const Char hex[] =3D STR("0123456789ABCDEF"); > ^ The rest of this note is about what I found when I looked into this. = Read only if you care. File for later if you likely would care later? =20= The libedit/Makefile uses -DWIDECHAR and libedit/chartype.h defines for = that case: > #define Char wchar_t > . . . > #define STR(x) L ## x > #define UC(c) c There were lots of warnings for incompatible pointer types for libedit/. = . . including the following one that was explicit about which type is = involved: > note: expected 'const wchar_t *' but argument is of type 'long int *' > int wcscmp(const wchar_t *, const wchar_t *) __pure; > ^ So how did the long int type end up involved? I expect the following may = contribute. Turns out that long int (and L suffix use in __WCHAR_MAX__) is specific = to 4.9.1 -m32 handling when compared to gcc 4.2.1 . . . > # gcc -dM -E -m32 - < /dev/null | grep WCHAR > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > # /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc-4.9.1 -dM -E -m32 - = < /dev/null | grep WCHAR > #define __WCHAR_MAX__ 2147483647L > #define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1) > #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2 > #define __WCHAR_TYPE__ long int > #define __SIZEOF_WCHAR_T__ 4 and compared to -m64 for both 4.2.1 and 4.9.1 . . . > # gcc -dM -E -m64 - < /dev/null | grep WCHAR > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > # /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc-4.9.1 -dM -E -m64 - = < /dev/null | grep WCHAR > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1) > #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2 > #define __WCHAR_TYPE__ int > #define __SIZEOF_WCHAR_T__ 4 (where I expect that __WCHAR_TYPE__ is the underlying type used for = wchar_t). The following ended up installed for the 4.9.1 compiler . . . > #undef WCHAR_TYPE > #define WCHAR_TYPE (TARGET_64BIT ? "int" : "long int") > #undef WCHAR_TYPE_SIZE > #define WCHAR_TYPE_SIZE 32 > = /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/plugin/include/conf= ig/rs6000/freebsd64.h > #undef WCHAR_TYPE > #define WCHAR_TYPE "long int" > #undef WCHAR_TYPE_SIZE > #define WCHAR_TYPE_SIZE 32 > = /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/plugin/include/conf= ig/rs6000/sysv4.h =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Sat Apr 11 23:59:00 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3558448A for ; Sat, 11 Apr 2015 23:59:00 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DA6C699C for ; Sat, 11 Apr 2015 23:58:59 +0000 (UTC) Received: (qmail 31574 invoked from network); 11 Apr 2015 23:58:51 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 11 Apr 2015 23:58:51 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sat, 11 Apr 2015 19:58:51 -0400 (EDT) Received: (qmail 22263 invoked from network); 11 Apr 2015 23:58:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Apr 2015 23:58:51 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id E3A151C43BC; Sat, 11 Apr 2015 16:58:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: gcc-4.9.1/gcc/config/rs6000/freebsd64.h vs. FreeBSD's powerpc (non-64) L"..." and wchar_t (other gcc ports too?) From: Mark Millard In-Reply-To: <5B228278-A967-46D4-8F56-08E47008D009@dsl-only.net> Date: Sat, 11 Apr 2015 16:58:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3734A273-6178-4AF5-B066-DEEB6CFC7F1C@dsl-only.net> References: <5B228278-A967-46D4-8F56-08E47008D009@dsl-only.net> To: freebsd-ports@freebsd.org, Warner Losh , Baptiste Daroussin X-Mailer: Apple Mail (2.2098) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 23:59:00 -0000 [The following may point to something that should be directed upstream = for gcc 4.9+ (and possibly earlier?) and/or something for the port(s) to = patch.] Short version: Looking at = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-4.9.1/gcc/config= /rs6000/freebsd64.h shows: > /* rs6000.h gets this wrong for FreeBSD. We use the GCC defaults = instead. */ > #undef WCHAR_TYPE > #define WCHAR_TYPE (TARGET_64BIT ? "int" : "long int") > #undef WCHAR_TYPE_SIZE > #define WCHAR_TYPE_SIZE 32 The above is what controls the type that results for L". . ." notation = no matter what the FreeBSD typedefs for wchar_t trace back to (int for = powerpc and powerpc64). For FreeBSD that long int should also be just int from what I can tell. = Why? . . . For it being long int: when trying WITH_LIB32=3D for buildworld with = powerpc64-xtoolchain-gcc's powerpc64-gcc port (on a powerpc64 box, using = WITHOUT_BOOT=3D ) this leads to the following in libedit: > . . . parse.c:181:25: error: array of inappropriate type initialized = from string constant > const Char hex[] =3D STR("0123456789ABCDEF"); > ^ where STR(". . .") produces L". . ." and Char traces back to wchar_t = (and back to int for the context). I also got lots of warnings about incompatible pointer types when Char = and STR(. . .) were in the mix for libedit. The ones that mention a type = explicitly mention long int *. I have not checked other processor families: I only have access to = PowerMac based FreeBSD's so far. I have not checked other gcc ports: Are gcc ports that are not = explicitly used for system builds supposed to be well behaved for L". . = ." notation vs. the FreeBSD wchar_t definition for C? If yes then they = likely need the same sort of adjustment. Details/evidence below: Ignore the following if the above is enough. The evidence for what was installed for powerpc64-gcc (on the powerpc64 = box) and what it will treat L". . ." as is: > # /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc-4.9.1 -dM -E -m32 - = < /dev/null | grep WCHAR > #define __WCHAR_MAX__ 2147483647L > #define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1) > #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2 > #define __WCHAR_TYPE__ long int > #define __SIZEOF_WCHAR_T__ 4 The above does not match what gcc 4.2.1 uses for __WCHAR_TYPE__ or what = -m64 uses for either gcc version. Those use int, like FreeBSD does. The long int use seems to be from following = gcc-4.9.1/gcc/config/rs6000/sysv4.h=E2=80=99s conventions for powerpc = (non-64) instead of following freebsd-=E2=80=99s wchar_t being int for = both powerpc and powerpc64: > $ /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc-4.9.1 -dM -E -m32 - = < /dev/null | sort | grep _CALL_ > #define _CALL_SYSV 1 > $ /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc-4.9.1 -dM -E -m64 - = < /dev/null | sort | grep _CALL_ > #define _CALL_AIX 1 > #define _CALL_AIXDESC 1 > #define _CALL_ELF 1 In other words: gcc 4.9.1=E2=80=99s freebsd64.h incorrectly assumes that = the call standard to follow drives the choice of underlying wchar_t type = for FreeBSD. The libedit/Makefile uses -DWIDECHAR and libedit/chartype.h defines for = that case: > #define Char wchar_t > . . . > #define STR(x) L ## x Note: I had WITHOUT_BOOT=3D for the experimental buildworld. WITH_BOOT=3D = has both some powerpc Makefile.inc problems (needing to use -Wl, = appropriately) and also there seems to be a lack of bindings for various = _restgpr__x compiler support routines so boot1.elf fails to link. So = I skipped that via WITHOUT_BOOT=3D so I could see what WITH_LIB32=3D = would do. =3D=3D=3D Mark Millard markmi at dsl-only.net