From owner-freebsd-arch@FreeBSD.ORG Sun Sep 14 09:00:39 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E8A852D for ; Sun, 14 Sep 2014 09:00:39 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F4E39FA for ; Sun, 14 Sep 2014 09:00:39 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s8E90XdI080736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Sep 2014 12:00:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s8E90XdI080736 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s8E90XZ5080735; Sun, 14 Sep 2014 12:00:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 14 Sep 2014 12:00:33 +0300 From: Konstantin Belousov To: Carsten Mattner Subject: Re: Intel MPX (Skylake ISA) support? Message-ID: <20140914090033.GA2737@kib.kiev.ua> References: <20140913162059.GU2737@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l0SlVHLU1TISIWpL" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 09:00:39 -0000 --l0SlVHLU1TISIWpL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 13, 2014 at 09:47:10PM +0200, Carsten Mattner wrote: > On Sat, Sep 13, 2014 at 6:20 PM, Konstantin Belousov > wrote: > > On Sat, Sep 13, 2014 at 12:45:16PM +0200, Carsten Mattner wrote: > >> Are there any plans to include the necessary (kernel, libc) support for > >> Intel MPX (https://en.wikipedia.org/wiki/Intel_MPX)? > > > > I looked at this several times. The 319433 (Instructions Set Extensions > > prog reference) even at the current revision 20 still seems to not prov= ide > > the complete documentation on the CPU side. E.g., could you point me at > > the description of the save area for MPX ? It is required since usermo= de > > bndcfg register can only be set by restoring from the XSAVE area. > > > > That said, I believe that most, if not all, of the needed kernel-side > > support is already there by the generic XSAVE code. > > > > I never see any specification of runtime services expected by the code > > generated by mpx-enabled gcc. >=20 > Is https://lkml.org/lkml/2014/9/11/182 helpful? Not for me. I have zero interest in reverse-engineering Linux code for core CPU functionality. Intel usually provides high-quality documentation for the processors, and I hope that they will provide all needed information together with the hardware release. Another significant missing piece is the lack of description of the initial state and expectation of the runtime support in the ABI document. The ABI draft 0.3 from July 17, 2013, specially edited for MPX, only talks about argument passing conventions and dwarf, it seems. It is curious discussion about non-feasibility of implementing MPX translation tables in usermode. Just for fun, I will try to do something purely in usermode (when/if hardware will be available). --l0SlVHLU1TISIWpL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUFVkxAAoJEJDCuSvBvK1BLn0P+wbB+reTsqJb+UrBaxmRyfnE WrspBbYMlD3vLFVE8bCR3Gy1CIHrwaS96DQWQW5V5gWvyXnMsfe+jKYSqBVegMkg V47JLbEmqjPXdSZEd7u4vxFVpaTFTJCkQgRKZJEIOe+wdxnfNzAJ8dK9mGfhE4lD f8CwdcZFuheM7aQajHHkC5nbCJ+eMeU1YkmKkdqVX+cojGwyk2RbsghctrygqpCg Sv/DlLgiKGHqb1Pkgpi3A35UyF8ZE1DrJkS8WY+IVWwkJ05oV/g+blX1UGsabn8i A1LKR0I43nKrDlr/zhkJ3asmPtxO/WNsLQddAvCyDLyJCO8jsvep4Nlzfu2aysBY j50vL+sBLQmDUm628WvZJhl8l39COQLobsP9yu05AJiqZusJR9mAbI3ozUruDT1g WU6/W1wfqieo3Wb4wDnB7bOxn4e1uhZwzssx9fLCjXfWOAadhoOVlbMsZsmuQm4x AGdeep2rfKwceFjg1EnhMHGBimZEaXRg5Hb+8dHy6wWri0C6GVDsJgOO4SL2Tsvm FSWryKG5rjef+56GCZkLeiG6FNPGtPnJuftYWZS6rpcWJ5yCL0Lgja6zZORwOXlZ BTdMtjhLgDBloVirCBbt6EhoTbdK6iEDXagJQtZMlz3XmvLMm1XBF3/LbqbaMTW/ JzPFhXsDOJ25Lh6+i0s1 =N7ZO -----END PGP SIGNATURE----- --l0SlVHLU1TISIWpL-- From owner-freebsd-arch@FreeBSD.ORG Sun Sep 14 09:18:12 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B823D2A for ; Sun, 14 Sep 2014 09:18:12 +0000 (UTC) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C8CD0BA4 for ; Sun, 14 Sep 2014 09:18:11 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id s18so3120661lam.0 for ; Sun, 14 Sep 2014 02:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=55h587AcfFIrXI2k/uBgPngp6V/oPphHreZKad6oAVQ=; b=ak8bOxWeYnmm2ffKP2g8pV+aJyRKpdupiq48QnrMbwlGaUWOqQqVtS9LXZdF9m6hIf vFTvr3PFUs6+ePYrlz8yVK9dXNx2hK6kujv+Gb0Q2896wa3p3Rq+B8S4DBiNZoRgkwxe SsPSD8hZ+j3FIycNlwd/y7d6qDFbnNHn/6qWezWutnMimETus4dPxUzQ5qxoKd4KXh8k t4c5zT/VKXMGxeqgcFxI/l2AHz29vH2xPsO/vfp5EJLI1HuyFODiM1AORhs0JdgpziOM sALRxyrLaMhua0TSZwe3BnWFuaLaRQ1wWqbInLKx2rJdqUvyVcNz4A3uoDuWLO2ujJFQ TcTg== MIME-Version: 1.0 X-Received: by 10.112.172.38 with SMTP id az6mr19276114lbc.53.1410686289750; Sun, 14 Sep 2014 02:18:09 -0700 (PDT) Received: by 10.25.42.83 with HTTP; Sun, 14 Sep 2014 02:18:09 -0700 (PDT) In-Reply-To: <20140914090033.GA2737@kib.kiev.ua> References: <20140913162059.GU2737@kib.kiev.ua> <20140914090033.GA2737@kib.kiev.ua> Date: Sun, 14 Sep 2014 11:18:09 +0200 Message-ID: Subject: Re: Intel MPX (Skylake ISA) support? From: Carsten Mattner To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 09:18:12 -0000 On Sun, Sep 14, 2014 at 11:00 AM, Konstantin Belousov wrote: > On Sat, Sep 13, 2014 at 09:47:10PM +0200, Carsten Mattner wrote: >> On Sat, Sep 13, 2014 at 6:20 PM, Konstantin Belousov >> wrote: >> > On Sat, Sep 13, 2014 at 12:45:16PM +0200, Carsten Mattner wrote: >> >> Are there any plans to include the necessary (kernel, libc) support for >> >> Intel MPX (https://en.wikipedia.org/wiki/Intel_MPX)? >> > >> > I looked at this several times. The 319433 (Instructions Set Extensions >> > prog reference) even at the current revision 20 still seems to not provide >> > the complete documentation on the CPU side. E.g., could you point me at >> > the description of the save area for MPX ? It is required since usermode >> > bndcfg register can only be set by restoring from the XSAVE area. >> > >> > That said, I believe that most, if not all, of the needed kernel-side >> > support is already there by the generic XSAVE code. >> > >> > I never see any specification of runtime services expected by the code >> > generated by mpx-enabled gcc. >> >> Is https://lkml.org/lkml/2014/9/11/182 helpful? > > Not for me. I have zero interest in reverse-engineering Linux code > for core CPU functionality. Intel usually provides high-quality > documentation for the processors, and I hope that they will provide all > needed information together with the hardware release. > > Another significant missing piece is the lack of description of the > initial state and expectation of the runtime support in the ABI > document. The ABI draft 0.3 from July 17, 2013, specially edited for > MPX, only talks about argument passing conventions and dwarf, it seems. > > It is curious discussion about non-feasibility of implementing MPX > translation tables in usermode. Just for fun, I will try to do > something purely in usermode (when/if hardware will be available). More details I was able to find with links to hopefully descriptive documentation. IIUC developers have been using a well known Intel CPU simulator, but I'm in the dark there. gcc: http://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler glibc: https://sourceware.org/ml/libc-alpha/2014-03/msg00491.html https://sourceware.org/ml/libc-alpha/2014-03/msg00543.html https://sourceware.org/ml/libc-alpha/2014-03/msg00605.html From owner-freebsd-arch@FreeBSD.ORG Sun Sep 14 18:16:40 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C406BDE for ; Sun, 14 Sep 2014 18:16:40 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 C50B23BA for ; Sun, 14 Sep 2014 18:16:39 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XTELk-000CjK-31; Sun, 14 Sep 2014 22:16:36 +0400 Date: Sun, 14 Sep 2014 22:16:36 +0400 From: Slawa Olhovchenkov To: Konstantin Belousov Subject: Re: Intel MPX (Skylake ISA) support? Message-ID: <20140914181636.GA47783@zxy.spb.ru> References: <20140913162059.GU2737@kib.kiev.ua> <20140914090033.GA2737@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140914090033.GA2737@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Carsten Mattner , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 18:16:40 -0000 On Sun, Sep 14, 2014 at 12:00:33PM +0300, Konstantin Belousov wrote: > On Sat, Sep 13, 2014 at 09:47:10PM +0200, Carsten Mattner wrote: > > On Sat, Sep 13, 2014 at 6:20 PM, Konstantin Belousov > > wrote: > > > On Sat, Sep 13, 2014 at 12:45:16PM +0200, Carsten Mattner wrote: > > >> Are there any plans to include the necessary (kernel, libc) support for > > >> Intel MPX (https://en.wikipedia.org/wiki/Intel_MPX)? > > > > > > I looked at this several times. The 319433 (Instructions Set Extensions > > > prog reference) even at the current revision 20 still seems to not provide > > > the complete documentation on the CPU side. E.g., could you point me at > > > the description of the save area for MPX ? It is required since usermode > > > bndcfg register can only be set by restoring from the XSAVE area. > > > > > > That said, I believe that most, if not all, of the needed kernel-side > > > support is already there by the generic XSAVE code. > > > > > > I never see any specification of runtime services expected by the code > > > generated by mpx-enabled gcc. > > > > Is https://lkml.org/lkml/2014/9/11/182 helpful? > > Not for me. I have zero interest in reverse-engineering Linux code > for core CPU functionality. Intel usually provides high-quality > documentation for the processors, and I hope that they will provide all > needed information together with the hardware release. > > Another significant missing piece is the lack of description of the > initial state and expectation of the runtime support in the ABI > document. The ABI draft 0.3 from July 17, 2013, specially edited for > MPX, only talks about argument passing conventions and dwarf, it seems. > > It is curious discussion about non-feasibility of implementing MPX > translation tables in usermode. Just for fun, I will try to do > something purely in usermode (when/if hardware will be available). https://software.intel.com/sites/default/files/managed/c6/a9/319433-020.pdf Cgapter 9. Total 30 pages. Also Intel SDE available. From owner-freebsd-arch@FreeBSD.ORG Sun Sep 14 22:26:22 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B8CAE78 for ; Sun, 14 Sep 2014 22:26:22 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id EB3B1E7F for ; Sun, 14 Sep 2014 22:26:21 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 48CC7346DE1B for ; Sun, 14 Sep 2014 15:26:21 -0700 (PDT) Message-ID: <54161633.60207@freebsd.org> Date: Sun, 14 Sep 2014 15:26:59 -0700 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: arch@freebsd.org Subject: Trouble with freebsd rc system. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 22:26:22 -0000 Hey folks, We are building an appliance based on FreeBSD. One of the issues we have is that during development we need to know which rc script we are in during boot so that if something is hanging or otherwise misbehaving we know which script it is. I am contemplating this hack to /etc/rc.subr's run_rc_command() method: run_rc_command() { _return=0 rc_arg=$1 if [ -z "$name" ]; then err 3 'run_rc_command: $name is not set.' fi # Don't repeat the first argument when passing additional command- # line arguments to the command subroutines. # shift 1 rc_extra_args="$*" echo "===> $name $rc_arg" As you can see I've added the call to echo so we know where we are. This is somewhat suboptimal because we really only want that output during startup. So a few questions: 1. Is there a way to know we are booting when inside of /etc/rc.subr:run_rc_command() ? 2. Is there a magic thing I'm missing that does what I want (output which /etc/rc.d/ script I am about to run)? 3. How would I make a knob to turn off the "echo" so that I can contribute this back to FreeBSD without getting into a bikeshed on bootup messages. Kindly please advise. -Alfred From owner-freebsd-arch@FreeBSD.ORG Sun Sep 14 22:41:01 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36BA32FA; Sun, 14 Sep 2014 22:41:01 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0B565F80; Sun, 14 Sep 2014 22:41:00 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XTITW-0001o8-CB; Sun, 14 Sep 2014 22:40:54 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s8EMerlO004035; Sun, 14 Sep 2014 16:40:53 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX185+TvIyCk3Vru20NDbvbul X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Trouble with freebsd rc system. From: Ian Lepore To: Alfred Perlstein In-Reply-To: <54161633.60207@freebsd.org> References: <54161633.60207@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Sun, 14 Sep 2014 16:40:53 -0600 Message-ID: <1410734453.66615.2.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 22:41:01 -0000 On Sun, 2014-09-14 at 15:26 -0700, Alfred Perlstein wrote: > Hey folks, > > We are building an appliance based on FreeBSD. > > One of the issues we have is that during development we need to know > which rc script we are in during boot so that if something is hanging or > otherwise misbehaving we know which script it is. > > I am contemplating this hack to /etc/rc.subr's run_rc_command() method: > > run_rc_command() > { > _return=0 > rc_arg=$1 > if [ -z "$name" ]; then > err 3 'run_rc_command: $name is not set.' > fi > > # Don't repeat the first argument when passing additional command- > # line arguments to the command subroutines. > # > shift 1 > rc_extra_args="$*" > > echo "===> $name $rc_arg" > > > As you can see I've added the call to echo so we know where we are. > > This is somewhat suboptimal because we really only want that output > during startup. > > So a few questions: > > 1. Is there a way to know we are booting when inside of > /etc/rc.subr:run_rc_command() ? > 2. Is there a magic thing I'm missing that does what I want (output > which /etc/rc.d/ script I am about to run)? > 3. How would I make a knob to turn off the "echo" so that I can > contribute this back to FreeBSD without getting into a bikeshed on > bootup messages. > > Kindly please advise. > > -Alfred A bit further down in run_rc_command, in the start) case, is: check_startmsgs && echo "Starting ${name}." and that output is controlled with rc_startmsgs=yes, which is the default. -- Ian From owner-freebsd-arch@FreeBSD.ORG Sun Sep 14 22:52:25 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0EF508DB; Sun, 14 Sep 2014 22:52:25 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id EF61019A; Sun, 14 Sep 2014 22:52:24 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id D02FF346DE1B; Sun, 14 Sep 2014 15:52:24 -0700 (PDT) Message-ID: <54161C50.3000507@freebsd.org> Date: Sun, 14 Sep 2014 15:53:04 -0700 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Trouble with freebsd rc system. References: <54161633.60207@freebsd.org> <1410734453.66615.2.camel@revolution.hippie.lan> In-Reply-To: <1410734453.66615.2.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 22:52:25 -0000 On 9/14/14, 3:40 PM, Ian Lepore wrote: > On Sun, 2014-09-14 at 15:26 -0700, Alfred Perlstein wrote: >> Hey folks, >> >> We are building an appliance based on FreeBSD. >> >> One of the issues we have is that during development we need to know >> which rc script we are in during boot so that if something is hanging or >> otherwise misbehaving we know which script it is. >> >> I am contemplating this hack to /etc/rc.subr's run_rc_command() method: >> >> run_rc_command() >> { >> _return=0 >> rc_arg=$1 >> if [ -z "$name" ]; then >> err 3 'run_rc_command: $name is not set.' >> fi >> >> # Don't repeat the first argument when passing additional command- >> # line arguments to the command subroutines. >> # >> shift 1 >> rc_extra_args="$*" >> >> echo "===> $name $rc_arg" >> >> >> As you can see I've added the call to echo so we know where we are. >> >> This is somewhat suboptimal because we really only want that output >> during startup. >> >> So a few questions: >> >> 1. Is there a way to know we are booting when inside of >> /etc/rc.subr:run_rc_command() ? >> 2. Is there a magic thing I'm missing that does what I want (output >> which /etc/rc.d/ script I am about to run)? >> 3. How would I make a knob to turn off the "echo" so that I can >> contribute this back to FreeBSD without getting into a bikeshed on >> bootup messages. >> >> Kindly please advise. >> >> -Alfred > A bit further down in run_rc_command, in the start) case, is: > > check_startmsgs && echo "Starting ${name}." > > and that output is controlled with rc_startmsgs=yes, which is the > default. > > -- Ian > > > I see that, however I've often been hung up in a rc script and that message is not displayed... let me check, maybe we have dumb defaults somehow. -Alfred From owner-freebsd-arch@FreeBSD.ORG Mon Sep 15 02:08:20 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA02D91A; Mon, 15 Sep 2014 02:08:20 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 5EE1C691; Mon, 15 Sep 2014 02:08:20 +0000 (UTC) Received: from [10.0.0.185] (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 1A1BF56447; Sun, 14 Sep 2014 21:08:18 -0500 (CDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Trouble with freebsd rc system. From: Eric van Gyzen In-Reply-To: <54161C50.3000507@freebsd.org> Date: Sun, 14 Sep 2014 22:08:16 -0400 Message-Id: <9B16D77C-0FD9-4A7B-AA13-009D0FC3A511@vangyzen.net> References: <54161633.60207@freebsd.org> <1410734453.66615.2.camel@revolution.hippie.lan> <54161C50.3000507@freebsd.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: arch@freebsd.org, Ian Lepore X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 02:08:20 -0000 On Sep 14, 2014, at 6:53 PM, Alfred Perlstein = wrote: >=20 > On 9/14/14, 3:40 PM, Ian Lepore wrote: >> On Sun, 2014-09-14 at 15:26 -0700, Alfred Perlstein wrote: >>> Hey folks, >>>=20 >>> We are building an appliance based on FreeBSD. >>>=20 >>> One of the issues we have is that during development we need to know >>> which rc script we are in during boot so that if something is = hanging or >>> otherwise misbehaving we know which script it is. >>>=20 >>> I am contemplating this hack to /etc/rc.subr's run_rc_command() = method: >>>=20 >>> run_rc_command() >>> { >>> _return=3D0 >>> rc_arg=3D$1 >>> if [ -z "$name" ]; then >>> err 3 'run_rc_command: $name is not set.' >>> fi >>>=20 >>> # Don't repeat the first argument when passing additional = command- >>> # line arguments to the command subroutines. >>> # >>> shift 1 >>> rc_extra_args=3D"$*" >>>=20 >>> echo "=3D=3D=3D> $name $rc_arg" >>>=20 >>>=20 >>> As you can see I've added the call to echo so we know where we are. >>>=20 >>> This is somewhat suboptimal because we really only want that output >>> during startup. >>>=20 >>> So a few questions: >>>=20 >>> 1. Is there a way to know we are booting when inside of >>> /etc/rc.subr:run_rc_command() ? >>> 2. Is there a magic thing I'm missing that does what I want (output >>> which /etc/rc.d/ script I am about to run)? >>> 3. How would I make a knob to turn off the "echo" so that I can >>> contribute this back to FreeBSD without getting into a bikeshed on >>> bootup messages. >>>=20 >>> Kindly please advise. >>>=20 >>> -Alfred >> A bit further down in run_rc_command, in the start) case, is: >>=20 >> check_startmsgs && echo "Starting ${name}." >>=20 >> and that output is controlled with rc_startmsgs=3Dyes, which is the >> default. >>=20 >> -- Ian >>=20 >>=20 >>=20 > I see that, however I've often been hung up in a rc script and that = message is not displayed... let me check, maybe we have dumb defaults = somehow. run_rc_script() sets up a signal hander for SIGINFO, so you can type = Ctrl-T to see which script is currently running. Eric= From owner-freebsd-arch@FreeBSD.ORG Mon Sep 15 09:59:44 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 066245FD; Mon, 15 Sep 2014 09:59:44 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A67AFA04; Mon, 15 Sep 2014 09:59:43 +0000 (UTC) Received: from [10.0.1.107] (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id AAF38346DE1D; Mon, 15 Sep 2014 02:59:37 -0700 (PDT) References: <54161633.60207@freebsd.org> <1410734453.66615.2.camel@revolution.hippie.lan> <54161C50.3000507@freebsd.org> <9B16D77C-0FD9-4A7B-AA13-009D0FC3A511@vangyzen.net> Mime-Version: 1.0 (1.0) In-Reply-To: <9B16D77C-0FD9-4A7B-AA13-009D0FC3A511@vangyzen.net> Message-Id: <0489D4F5-12F6-4FDD-91D0-AB6DC325ADFF@mu.org> X-Mailer: iPhone Mail (11D257) From: Alfred Perlstein Subject: Re: Trouble with freebsd rc system. Date: Mon, 15 Sep 2014 02:59:32 -0700 To: Eric van Gyzen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "arch@freebsd.org" , Alfred Perlstein , Ian Lepore X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 09:59:44 -0000 > On Sep 14, 2014, at 7:08 PM, Eric van Gyzen wrote: >=20 >> On Sep 14, 2014, at 6:53 PM, Alfred Perlstein wrote:= >>>=20 >> I see that, however I've often been hung up in a rc script and that messa= ge is not displayed... let me check, maybe we have dumb defaults somehow. >=20 > run_rc_script() sets up a signal hander for SIGINFO, so you can type Ctrl-= T to see which script is currently running. >=20 We would just like it to display regardless for our customers. The hitting c= trl-t step is nice for me, but doesn't work for deployments. =20 I'll see what's up.=20 We are on 10-stable from June ish. I can get exact date shortly. Was wonderi= ng if this show_rc_conmand is available in -stable a few months back.=20= From owner-freebsd-arch@FreeBSD.ORG Tue Sep 16 03:37:56 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D2B0E56 for ; Tue, 16 Sep 2014 03:37:56 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5294AA98 for ; Tue, 16 Sep 2014 03:37:56 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id n8so4909490qaq.40 for ; Mon, 15 Sep 2014 20:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sptQ+RRpWjQ1FY3Haclgz+AAegFkpRF0icNkdTzaXuc=; b=ZBGrKBNHu46erLhOB8CusWMwnpeKvRm8IG8NG9Ofuojyi0BlEo7wbe7xkaMR/mGTZo fTVEp6KC8yR/X2OaOKS1NtsixWxGgErKGxIC6E99+NBWjJHWoa5ytAP2QjLlaFmCWBA8 vk6of22PzwVQKh7cWXyEiOujp2Oyov6MuKUJRZ61AbteW/w+ASDjk2+4R20S5E5gq8al VAdSMPUvmbQMXE+g3IZqrZ8d8PjMmsLjGPBLM/qe9fwDZD9XTndetUGdFtWJGQl8sCXP WIC+YbNCWA8NKl0uLaPmgRPwRXA0mKUOLU0IzqH8X82FLBnj7GjuWJ7MsopXym1/bby5 y7jQ== MIME-Version: 1.0 X-Received: by 10.224.75.73 with SMTP id x9mr43154916qaj.63.1410838675413; Mon, 15 Sep 2014 20:37:55 -0700 (PDT) Received: by 10.224.39.139 with HTTP; Mon, 15 Sep 2014 20:37:55 -0700 (PDT) Date: Mon, 15 Sep 2014 20:37:55 -0700 Message-ID: Subject: [rfc] [rft] change intr_event_bind() / ie_assign_cpu cpuid to int From: Adrian Chadd To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 03:37:56 -0000 Hi! This patch changes the ie_assign_cpu bit in the interrupt struct to use an int instead of a u_char for a CPUID. https://people.freebsd.org/~adrian/smp/20140915-intr-bind-cpuid-1.diff I'd like some initial feedback on this. Yes, it's not cpuid_t (although this all may end up becoming a uint32_t at some point soon) but it does touch a few pieces of hardware I actually don't have and don't know if I can emulate correctly. Thanks! -a From owner-freebsd-arch@FreeBSD.ORG Tue Sep 16 08:33:51 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC9D3A4B for ; Tue, 16 Sep 2014 08:33:51 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6E344910 for ; Tue, 16 Sep 2014 08:33:51 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s8G8XhWr043065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Sep 2014 11:33:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s8G8XhWr043065 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s8G8Xhcw043064; Tue, 16 Sep 2014 11:33:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 16 Sep 2014 11:33:43 +0300 From: Konstantin Belousov To: Carsten Mattner Subject: Re: Intel MPX (Skylake ISA) support? Message-ID: <20140916083343.GS2737@kib.kiev.ua> References: <20140913162059.GU2737@kib.kiev.ua> <20140914090033.GA2737@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xK0oco9ieugCOMaM" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 08:33:52 -0000 --xK0oco9ieugCOMaM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 14, 2014 at 11:18:09AM +0200, Carsten Mattner wrote: > More details I was able to find with links to hopefully descriptive > documentation. IIUC developers have been using a well known > Intel CPU simulator, but I'm in the dark there. SDE does not run on FreeBSD, and setting up Linux (or Windows) for this is out of question, at least for me. >=20 > gcc: http://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20com= piler >=20 > glibc: > https://sourceware.org/ml/libc-alpha/2014-03/msg00491.html > https://sourceware.org/ml/libc-alpha/2014-03/msg00543.html > https://sourceware.org/ml/libc-alpha/2014-03/msg00605.html I can google as well. I have no intend of reverse-engineering Linux code to get basic information about CPU core. Why are you so insisted on the non-released feature, which seemingly still lacks complete documentation ? Yes, something can be done even now, but that requires a lot of efforts, backed by a huge belief into the world-shaking nature of the MPX and inability to wait even a bit to get hands on it. I do not have that urge, and do not understand why do you try to trick others into it. Will you provide the hardware to the developers when it become generally avaiable ? FWIW, it would be very useful if Jim Harris chimed in. --xK0oco9ieugCOMaM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUF/XmAAoJEJDCuSvBvK1BDvMP/0f0HNbeaUpRF71UiTPVMukz yRp2RzduC9/+GPnDW2rB/nZsU8r57lFcpgvaS7aOAfN2iol47ve3eLwGJ1WbzJoS Tkmd18U0BBEA0nLaZqraXIu7j9e9gMLJvDOEPOD525esc/S6xs4MYKl278HFkrjQ lTLWoTzA906uL8hIho02FojuoyXTGgEFX+obM4pEj92kkpAzSssjDXa3wqUibjuP sCmP5JCcWLbX2iAe3Fi1cRI1ATCAVEuJmekR27vZIqZzIzZN1BGsSE0cL8XYcsCl B1/vGVCYfJhwVanD2mvAZ3wKt/flgcrokGQRBBx22/7euXeAvfZpBJpCmKyx7Iqt c1mni6SUflNgtu6aoZ5dtTRiwhdGO0cpruxcwP8DQmlg1VpoCgDAAMtC0gPbjuxx 8Y+3704w2auyzwVP+9somCD4ujswRcJadyaPWhF1h6Z38NRg3IkSe0kYDIVJmxQ1 A6wvIM18Xh4F1z0ZN4xtlD4egin4RM93DycusoL66YbeYz75i6rBW9mJFXO5VnGm 1G7TPSDSyrfojWfrGDoBHNbWzeXZEeEigCqiWvur2yb+Zw1bFU67KqVbZDSWP1ay 6S4dLV2bIPiuLB79CA+tojP9FhuO26DlYjMxy1W1pux5v85d9qe4rwX6ndu5+u79 p4/MNHC7rCzGIZG4AKi4 =4nTq -----END PGP SIGNATURE----- --xK0oco9ieugCOMaM-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 16 13:50:07 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93BA6ACA for ; Tue, 16 Sep 2014 13:50:07 +0000 (UTC) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 18EAEF96 for ; Tue, 16 Sep 2014 13:50:06 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id z11so6434899lbi.26 for ; Tue, 16 Sep 2014 06:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xNmA+cW9Yvehm11IQ1DjLFHxFdRdF6jFlXJUTonIL18=; b=UUCAhTmCX6kykwPjsWynMSwrNsOOB8WVZFvRFfeJcAss938Pxj2OwBlTh6ukkloSTX uewc9rC1hLuFmfutqXI9MgyeepUfLpvQL+dlgNJkjGPj4aBE5e3XpyTEa5TtgLpsIIwj mcNbuOGhcolc6kpCEeHsAKSlNEtriZqr9POiXeGH/bOLW1eWvRBESH2FZvmmnpDBbGH3 NcUObU1mM8O5l5ttVOrCYXqBL2Gvv0++gfx1GmcAzzYbhefyrAW+TnO3pHGryMaqN12O VLPdiVxKjxu+DTnx0tH5avGfiGf1pkt+V3v6q9PUE1S2+LRIrBoHM8eZpshjwfn0pPJR ALkQ== MIME-Version: 1.0 X-Received: by 10.152.22.137 with SMTP id d9mr37098525laf.29.1410875403459; Tue, 16 Sep 2014 06:50:03 -0700 (PDT) Received: by 10.25.133.213 with HTTP; Tue, 16 Sep 2014 06:50:03 -0700 (PDT) In-Reply-To: <20140916083343.GS2737@kib.kiev.ua> References: <20140913162059.GU2737@kib.kiev.ua> <20140914090033.GA2737@kib.kiev.ua> <20140916083343.GS2737@kib.kiev.ua> Date: Tue, 16 Sep 2014 15:50:03 +0200 Message-ID: Subject: Re: Intel MPX (Skylake ISA) support? From: Carsten Mattner To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 13:50:07 -0000 On Tue, Sep 16, 2014 at 10:33 AM, Konstantin Belousov wrote: > On Sun, Sep 14, 2014 at 11:18:09AM +0200, Carsten Mattner wrote: >> More details I was able to find with links to hopefully descriptive >> documentation. IIUC developers have been using a well known >> Intel CPU simulator, but I'm in the dark there. > SDE does not run on FreeBSD, and setting up Linux (or Windows) for this > is out of question, at least for me. > >> >> gcc: http://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler >> >> glibc: >> https://sourceware.org/ml/libc-alpha/2014-03/msg00491.html >> https://sourceware.org/ml/libc-alpha/2014-03/msg00543.html >> https://sourceware.org/ml/libc-alpha/2014-03/msg00605.html > > I can google as well. I have no intend of reverse-engineering Linux code > to get basic information about CPU core. > > Why are you so insisted on the non-released feature, which seemingly > still lacks complete documentation ? Yes, something can be done even > now, but that requires a lot of efforts, backed by a huge belief into > the world-shaking nature of the MPX and inability to wait even a bit to After going over the chapter in the ISA pdf the feature doesn't look as useful as I thought it would be and it's only to prevent buffer underrun/overrun - no other widespread vector is closed. > get hands on it. I do not have that urge, and do not understand why do > you try to trick others into it. Will you provide the hardware to the > developers when it become generally avaiable ? Sorry you think I'm trying to trick anyone - that couldn't be further from the truth but English is not my native language and I maybe misrepresented the question. > FWIW, it would be very useful if Jim Harris chimed in. From owner-freebsd-arch@FreeBSD.ORG Tue Sep 16 14:11:05 2014 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1262B75F for ; Tue, 16 Sep 2014 14:11:05 +0000 (UTC) Received: from out11.biz.mail.alibaba.com (out11.biz.mail.alibaba.com [205.204.114.131]) by mx1.freebsd.org (Postfix) with ESMTP id 5D2DE34B for ; Tue, 16 Sep 2014 14:11:04 +0000 (UTC) Received: from WS-web by r46d02007.xy2.aliyun.com at Tue, 16 Sep 2014 22:04:27 +0800 Date: Tue, 16 Sep 2014 22:04:25 +0800 From: Sender: To: Message-ID: <9adf0f10-8928-4dd4-a3bb-89dd9ce7bceb@laptoppartsupply.com> Subject: =?UTF-8?B?UHJvZmVzc2lvbmFsIE1hbnVmYWN0dXJlIExhcHRvcCBBQyBBZGFwdGVyICA=?= X-Priority: 3 X-Mailer: Alimail-Mailagent MIME-Version: 1.0 X-Alimail-AntiSpam: AC=CONTINUE; BC=0.3325399|-1; FP=18437547478380499065|6|1|203|0|-1|-1|-1; HT=r41g03021; MF=sales03@laptoppartsupply.com; PH=DW; RN=50; RT=50; SR=0; X-Priority: 3 X-Mailer: Alimail-Mailagent revision 2658173 Sender: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 14:11:05 -0000 SGkgDQpkZWFyIEZyaWVuZCwNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCsKg DQoNCldlIGhhdmUgdGhlIHBsZWFzdXJlIG9mIGNvbnRhY3Rpbmcgd2l0aCB5b3UgDQp0b2RheS4N Cg0KwqANCg0KDQpXZSdyZSBhIGxlYWRpbmcgbWFudWZhY3R1cmVyIG9mIGFsbCBraW5kcyBvZiBs YXB0b3AgDQphZGFwdGVycywgY29uY2x1ZGluZyBVbm5pdmVyc2FsIEFDL0NhciBhZGFwdGVyLCBU YWJsZXQgYWRhcHRlciwgV2FsbCBNb3VudCANCmFkYXB0ZXIsIE1pbmkgYWRhcHRlciwgT3JpZ2lu YWwgYWRhcHRlciBhbmQgbW9yZSwgYXMgd2VsbCBhcyBsYXB0b3AgYmF0dGVyaWVzIA0KYW5kIElw b25lIGFjY2Vzc29yaWVzLiBBbGwgdGhlc2UgYWNjb3VudCBtb3JlIHRoYW4gMTAwMCBtb2RlbHMg d2l0aCBtb3JlIHRoYW4gMSANCnllYXIgd2FycmFudHkgYW5kIG5vIE1PUS4NCg0KwqANCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpTaG91bGQgeW91IGhhdmUgYW55IHF1ZXN0aW9ucyBvciBpbnF1aXJl cywgcGxlYXNlIGRvIG5vdCANCmhlc2l0YXRlIHRvIGxldCBtZSBrbm93Lg0KDQrCoA0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCldlIHdvdWxkIGJlIHRoYW5rZnVsIHRvIGNvb3BlcmF0ZSB3aXRoIA0K eW91Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KVGhhbmtzIGFuZCBCZXN0IFJlZ2FyZHMhDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCkJldHR5IChzYWxlcyANCm1hbmFnZXIpDQoNCg0KDQoNCg0KwqANCg0K U2hlbnpoZW4gSG9uZ2RhIFNodW4gDQpUZWNobm9sb2d5IERldmVsb3BtZW50IENvLixMdGQuDQoN CkhLIEZseWluZyANCkludGVybmF0aW9uYWwgQ28uLExpbWl0ZWQNCg0KRS1tYWlsOnNhbGVzMDRA aHVuZGFwb3dlci5jb207IFNreXBlOmZ5YWRhcHRlcsKgIA0KSUNROjYxMjYyMzQ0Ng0KDQpXZWJz aXRlOsKgaHR0cDovL3d3dy5meS1hZGFwdGVyLmNvbTvCoGh0dHA6Ly93d3cuaHVuZGFwb3dlci5j b207wqBodHRwOi8vaG9uZ2Rhc2h1bi5lbi5hbGliYWJhLmNvbS8NCg0KQWRkcmVzczo0MDEtMixO by4yMTgtMixIZW5hbiANCk5ldyBWaWxsYWdlLERhZnUgQ29tbXVuaXR5LEd1YW5sYW4sTG9uZ2h1 YSBOZXcgDQpEaXN0cmljdCxTaGVuemhlbixHdWFuZ2RvbmcsQ2hpbmEuDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQo= From owner-freebsd-arch@FreeBSD.ORG Tue Sep 16 16:06:38 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECB95FF0 for ; Tue, 16 Sep 2014 16:06:38 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 CB649315 for ; Tue, 16 Sep 2014 16:06:38 +0000 (UTC) Received: from [192.168.200.200] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id ADE7A193FD5 for ; Tue, 16 Sep 2014 16:06:36 +0000 (UTC) Subject: Re: Total confusion over toolchain/xdev behavior [redux] From: Sean Bruno Reply-To: sbruno@freebsd.org To: freebsd-arch In-Reply-To: <1404688077.1059.115.camel@bruno> References: <1404688077.1059.115.camel@bruno> Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Sep 2014 09:06:33 -0700 Message-ID: <1410883593.10088.9.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 16:06:39 -0000 On Sun, 2014-07-06 at 16:07 -0700, Sean Bruno wrote: > Objective: install an xcompile toolchain into a jail for use by > poudriere during arm/mips/sparc/power ports pkgs builds. The build > should be possible from a non-root user. We've had a lot of success using Warner's native-xtools target to build a toolchain inserted into a native armv6 chroot, emulated via qemu-bsd-user with the binmisc image activator handling things for us. I've run into, what appears to be, a tool chain setup problem that I don't quite grok. I suspect, we are not setting up the amd64-clang toolchain inserted into the jail correctly. I.e. we are using an external toolchain here, that is amd64 binaries configured to output armv6 (all clang). I have identified a list of several ports (probably 40 or 50) that seem to have the same failure case when "linking". Some are hidden by "configure" while most fail the same way. In general it looks like this: rm -f bltwish25 /nxb-bin/usr/bin/cc -Wall -fPIC -O -pipe -I/usr/local/include/tcl8.6/generic -I/usr/local/include/tk8.6/generic -I/usr/local/include/tk8.6/unix -DUSE_INTERP_RESULT -DUSE_INTERP_ERRORLINE -I.. -I./.. -I./../.. -I/usr/local/include -I/usr/local/include/tk8.6 -I/usr/local/include/tcl8.6 -o bltwish25 \ ./../bltUnixMain.c libBLT25.so -L/usr/local/lib -ltk86 -ltcl86 -LNONE -lX11 -L/usr/local/lib -ljpeg -lm /nxb-bin/usr/bin/ld: bltwish25: hidden symbol `__aeabi_memcpy' in /usr/lib/libgcc.a(aeabi_memcpy.o) is referenced by DSO /nxb-bin/usr/bin/ld: final link failed: Nonrepresentable section on output cc: error: linker command failed with exit code 1 (use -v to see invocation) gmake[3]: *** [bltwish25] Error 1 full build log: http://chips.ysv.freebsd.org/data/11armv632-default/2014-09-04_01h04m05s/logs/errors/blt-2.5.3_2.log From owner-freebsd-arch@FreeBSD.ORG Tue Sep 16 17:20:47 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 210A9367; Tue, 16 Sep 2014 17:20:47 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7DF9E59; Tue, 16 Sep 2014 17:20:46 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XTwQn-000HCd-CD; Tue, 16 Sep 2014 17:20:45 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s8GHKinL007944; Tue, 16 Sep 2014 11:20:44 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+Lz5A/zhvt00qDFBzLPtcW X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Total confusion over toolchain/xdev behavior [redux] From: Ian Lepore To: sbruno@freebsd.org In-Reply-To: <1410883593.10088.9.camel@bruno> References: <1404688077.1059.115.camel@bruno> <1410883593.10088.9.camel@bruno> Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Sep 2014 11:20:44 -0600 Message-ID: <1410888044.66615.7.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 17:20:47 -0000 On Tue, 2014-09-16 at 09:06 -0700, Sean Bruno wrote: > On Sun, 2014-07-06 at 16:07 -0700, Sean Bruno wrote: > > Objective: install an xcompile toolchain into a jail for use by > > poudriere during arm/mips/sparc/power ports pkgs builds. The build > > should be possible from a non-root user. > > We've had a lot of success using Warner's native-xtools target to build > a toolchain inserted into a native armv6 chroot, emulated via > qemu-bsd-user with the binmisc image activator handling things for us. > > I've run into, what appears to be, a tool chain setup problem that I > don't quite grok. I suspect, we are not setting up the amd64-clang > toolchain inserted into the jail correctly. I.e. we are using an > external toolchain here, that is amd64 binaries configured to output > armv6 (all clang). > > I have identified a list of several ports (probably 40 or 50) that seem > to have the same failure case when "linking". Some are hidden by > "configure" while most fail the same way. In general it looks like > this: > > rm -f bltwish25 > /nxb-bin/usr/bin/cc -Wall -fPIC -O -pipe -I/usr/local/include/tcl8.6/generic -I/usr/local/include/tk8.6/generic -I/usr/local/include/tk8.6/unix -DUSE_INTERP_RESULT -DUSE_INTERP_ERRORLINE -I.. -I./.. -I./../.. -I/usr/local/include -I/usr/local/include/tk8.6 -I/usr/local/include/tcl8.6 -o bltwish25 \ > ./../bltUnixMain.c libBLT25.so -L/usr/local/lib -ltk86 -ltcl86 -LNONE -lX11 -L/usr/local/lib -ljpeg -lm > /nxb-bin/usr/bin/ld: bltwish25: hidden symbol `__aeabi_memcpy' in /usr/lib/libgcc.a(aeabi_memcpy.o) is referenced by DSO > /nxb-bin/usr/bin/ld: final link failed: Nonrepresentable section on output > cc: error: linker command failed with exit code 1 (use -v to see invocation) > gmake[3]: *** [bltwish25] Error 1 > > full build log: > http://chips.ysv.freebsd.org/data/11armv632-default/2014-09-04_01h04m05s/logs/errors/blt-2.5.3_2.log > It looks like this might be the fix for the problem. Unfortunately, at least parts of it are gpl3... https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=151568 -- Ian From owner-freebsd-arch@FreeBSD.ORG Tue Sep 16 17:44:57 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95254F84; Tue, 16 Sep 2014 17:44:57 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 7309D1D0; Tue, 16 Sep 2014 17:44:57 +0000 (UTC) Received: from [192.168.200.200] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 9E3EF19413C; Tue, 16 Sep 2014 17:44:55 +0000 (UTC) Subject: Re: Total confusion over toolchain/xdev behavior [redux] From: Sean Bruno Reply-To: sbruno@freebsd.org To: Ian Lepore In-Reply-To: <1410888044.66615.7.camel@revolution.hippie.lan> References: <1404688077.1059.115.camel@bruno> <1410883593.10088.9.camel@bruno> <1410888044.66615.7.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Sep 2014 10:44:53 -0700 Message-ID: <1410889493.10088.11.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 17:44:57 -0000 On Tue, 2014-09-16 at 11:20 -0600, Ian Lepore wrote: > On Tue, 2014-09-16 at 09:06 -0700, Sean Bruno wrote: > > On Sun, 2014-07-06 at 16:07 -0700, Sean Bruno wrote: > > > Objective: install an xcompile toolchain into a jail for use by > > > poudriere during arm/mips/sparc/power ports pkgs builds. The build > > > should be possible from a non-root user. > > > > We've had a lot of success using Warner's native-xtools target to build > > a toolchain inserted into a native armv6 chroot, emulated via > > qemu-bsd-user with the binmisc image activator handling things for us. > > > > I've run into, what appears to be, a tool chain setup problem that I > > don't quite grok. I suspect, we are not setting up the amd64-clang > > toolchain inserted into the jail correctly. I.e. we are using an > > external toolchain here, that is amd64 binaries configured to output > > armv6 (all clang). > > > > I have identified a list of several ports (probably 40 or 50) that seem > > to have the same failure case when "linking". Some are hidden by > > "configure" while most fail the same way. In general it looks like > > this: > > > > rm -f bltwish25 > > /nxb-bin/usr/bin/cc -Wall -fPIC -O -pipe -I/usr/local/include/tcl8.6/generic -I/usr/local/include/tk8.6/generic -I/usr/local/include/tk8.6/unix -DUSE_INTERP_RESULT -DUSE_INTERP_ERRORLINE -I.. -I./.. -I./../.. -I/usr/local/include -I/usr/local/include/tk8.6 -I/usr/local/include/tcl8.6 -o bltwish25 \ > > ./../bltUnixMain.c libBLT25.so -L/usr/local/lib -ltk86 -ltcl86 -LNONE -lX11 -L/usr/local/lib -ljpeg -lm > > /nxb-bin/usr/bin/ld: bltwish25: hidden symbol `__aeabi_memcpy' in /usr/lib/libgcc.a(aeabi_memcpy.o) is referenced by DSO > > /nxb-bin/usr/bin/ld: final link failed: Nonrepresentable section on output > > cc: error: linker command failed with exit code 1 (use -v to see invocation) > > gmake[3]: *** [bltwish25] Error 1 > > > > full build log: > > http://chips.ysv.freebsd.org/data/11armv632-default/2014-09-04_01h04m05s/logs/errors/blt-2.5.3_2.log > > > > It looks like this might be the fix for the problem. Unfortunately, at > least parts of it are gpl3... > > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=151568 > > -- Ian > > ok, I'll give it a try here. However, do I need different changes for config.gcc than are displayed in the file? sean From owner-freebsd-arch@FreeBSD.ORG Tue Sep 16 19:38:27 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C275C27 for ; Tue, 16 Sep 2014 19:38:27 +0000 (UTC) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2001:470:8b2d:1e1c:21b:21ff:feb8:d7b0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "khavrinen.csail.mit.edu", Issuer "Client CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D44010C for ; Tue, 16 Sep 2014 19:38:27 +0000 (UTC) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s8GJcP7f029344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA) for ; Tue, 16 Sep 2014 15:38:25 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.14.7/8.14.7/Submit) id s8GJcOVi029341; Tue, 16 Sep 2014 15:38:24 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21528.37296.395002.628214@khavrinen.csail.mit.edu> Date: Tue, 16 Sep 2014 15:38:24 -0400 From: Garrett Wollman To: freebsd-arch@freebsd.org Subject: OpLog: a library for scaling update-heavy data structures X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (khavrinen.csail.mit.edu [127.0.0.1]); Tue, 16 Sep 2014 15:38:25 -0400 (EDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 19:38:27 -0000 I just wanted to point out the following recent publication by people who happen to work in the same building as I do: OpLog: a library for scaling update-heavy data structures Author: Boyd-Wickizer, Silas; Kaashoek, M. Frans; Morris, Robert; Zeldovich, Nickolai Citable URI: http://hdl.handle.net/1721.1/89653 Other Contributors: Parallel and Distributed Operating Systems Advisor: Nickolai Zeldovich Date Issued: 2014-09-16 Abstract: Existing techniques (e.g., RCU) can achieve good multi-core scaling for read-mostly data, but for update-heavy data structures only special-purpose techniques exist. This paper presents OpLog, a general-purpose library supporting good scalability for update-heavy data structures. OpLog achieves scalability by logging each update in a low-contention per-core log; it combines logs only when required by a read to the data structure. OpLog achieves generality by logging operations without having to understand them, to ease application to existing data structures. OpLog can further increase performance if the programmer indicates which operations can be combined in the logs. An evaluation shows how to apply OpLog to three update-heavy Linux kernel data structures. Measurements on a 48-core AMD server show that the result significantly improves the performance of the Apache web server and the Exim mail server under certain workloads. URI: http://hdl.handle.net/1721.1/89653 Series/Report no.: MIT-CSAIL-TR-2014-019 -GAWollman From owner-freebsd-arch@FreeBSD.ORG Fri Sep 19 18:28:18 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38E90D81; Fri, 19 Sep 2014 18:28:18 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 172D097B; Fri, 19 Sep 2014 18:28:17 +0000 (UTC) Received: from [192.168.200.200] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 283F8194170; Fri, 19 Sep 2014 18:28:16 +0000 (UTC) Subject: Re: Total confusion over toolchain/xdev behavior [redux] From: Sean Bruno Reply-To: sbruno@freebsd.org To: Ian Lepore In-Reply-To: <1410888044.66615.7.camel@revolution.hippie.lan> References: <1404688077.1059.115.camel@bruno> <1410883593.10088.9.camel@bruno> <1410888044.66615.7.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Sep 2014 11:28:15 -0700 Message-ID: <1411151295.2868.2.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 18:28:18 -0000 On Tue, 2014-09-16 at 11:20 -0600, Ian Lepore wrote: > On Tue, 2014-09-16 at 09:06 -0700, Sean Bruno wrote: > > On Sun, 2014-07-06 at 16:07 -0700, Sean Bruno wrote: > > > Objective: install an xcompile toolchain into a jail for use by > > > poudriere during arm/mips/sparc/power ports pkgs builds. The build > > > should be possible from a non-root user. > > > > We've had a lot of success using Warner's native-xtools target to build > > a toolchain inserted into a native armv6 chroot, emulated via > > qemu-bsd-user with the binmisc image activator handling things for us. > > > > I've run into, what appears to be, a tool chain setup problem that I > > don't quite grok. I suspect, we are not setting up the amd64-clang > > toolchain inserted into the jail correctly. I.e. we are using an > > external toolchain here, that is amd64 binaries configured to output > > armv6 (all clang). > > > > I have identified a list of several ports (probably 40 or 50) that seem > > to have the same failure case when "linking". Some are hidden by > > "configure" while most fail the same way. In general it looks like > > this: > > > > rm -f bltwish25 > > /nxb-bin/usr/bin/cc -Wall -fPIC -O -pipe -I/usr/local/include/tcl8.6/generic -I/usr/local/include/tk8.6/generic -I/usr/local/include/tk8.6/unix -DUSE_INTERP_RESULT -DUSE_INTERP_ERRORLINE -I.. -I./.. -I./../.. -I/usr/local/include -I/usr/local/include/tk8.6 -I/usr/local/include/tcl8.6 -o bltwish25 \ > > ./../bltUnixMain.c libBLT25.so -L/usr/local/lib -ltk86 -ltcl86 -LNONE -lX11 -L/usr/local/lib -ljpeg -lm > > /nxb-bin/usr/bin/ld: bltwish25: hidden symbol `__aeabi_memcpy' in /usr/lib/libgcc.a(aeabi_memcpy.o) is referenced by DSO > > /nxb-bin/usr/bin/ld: final link failed: Nonrepresentable section on output > > cc: error: linker command failed with exit code 1 (use -v to see invocation) > > gmake[3]: *** [bltwish25] Error 1 > > > > full build log: > > http://chips.ysv.freebsd.org/data/11armv632-default/2014-09-04_01h04m05s/logs/errors/blt-2.5.3_2.log > > > > It looks like this might be the fix for the problem. Unfortunately, at > least parts of it are gpl3... > > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=151568 > > -- Ian > > I tried this, and it didn't seem to help, I suspect I need the gcc.config changes too in some way? https://people.freebsd.org/~sbruno/gcc_libs.txt sean From owner-freebsd-arch@FreeBSD.ORG Sat Sep 20 09:56:02 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAAC6874 for ; Sat, 20 Sep 2014 09:56:02 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 9D97E7D2 for ; Sat, 20 Sep 2014 09:56:02 +0000 (UTC) Received: from bender.lan (97e07ab1.skybroadband.com [151.224.122.177]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 8965D5CBF4; Sat, 20 Sep 2014 09:55:54 +0000 (UTC) Date: Sat, 20 Sep 2014 10:55:47 +0100 From: Andrew Turner To: Sean Bruno Subject: Re: Total confusion over toolchain/xdev behavior [redux] Message-ID: <20140920105547.673a54de@bender.lan> In-Reply-To: <1410883593.10088.9.camel@bruno> References: <1404688077.1059.115.camel@bruno> <1410883593.10088.9.camel@bruno> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 09:56:02 -0000 On Tue, 16 Sep 2014 09:06:33 -0700 Sean Bruno wrote: ... > I've run into, what appears to be, a tool chain setup problem that I > don't quite grok. I suspect, we are not setting up the amd64-clang > toolchain inserted into the jail correctly. I.e. we are using an > external toolchain here, that is amd64 binaries configured to output > armv6 (all clang). > > I have identified a list of several ports (probably 40 or 50) that > seem to have the same failure case when "linking". Some are hidden by > "configure" while most fail the same way. In general it looks like > this: > > rm -f bltwish25 > /nxb-bin/usr/bin/cc -Wall -fPIC -O -pipe > -I/usr/local/include/tcl8.6/generic > -I/usr/local/include/tk8.6/generic -I/usr/local/include/tk8.6/unix > -DUSE_INTERP_RESULT -DUSE_INTERP_ERRORLINE -I.. -I./.. -I./../.. > -I/usr/local/include -I/usr/local/include/tk8.6 > -I/usr/local/include/tcl8.6 -o bltwish25 \ ./../bltUnixMain.c > libBLT25.so -L/usr/local/lib -ltk86 -ltcl86 -LNONE -lX11 > -L/usr/local/lib -ljpeg -lm /nxb-bin/usr/bin/ld: bltwish25: hidden > symbol `__aeabi_memcpy' in /usr/lib/libgcc.a(aeabi_memcpy.o) is > referenced by DSO /nxb-bin/usr/bin/ld: final link failed: > Nonrepresentable section on output cc: error: linker command failed > with exit code 1 (use -v to see invocation) gmake[3]: *** [bltwish25] > Error 1 > > full build log: > http://chips.ysv.freebsd.org/data/11armv632-default/2014-09-04_01h04m05s/logs/errors/blt-2.5.3_2.log The problem is the port is attempting to link the shared objects using ld directly however it's not linking these against libgcc which provides the needed symbol. The simple fix is to change the port to use the compiler to link the .so files. I've submitted a patch for the port to do this at [1]. With this patch I can build the port with no error. I don't know what the other ports are so am unable to look into if these have the same problem. A simple check is to see if they use cc or ld to perform the linking. Clang and gcc should both do the right thing and link against libgcc as needed. Andrew [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193791