From owner-freebsd-ppc@freebsd.org Sun Feb 7 05:58:33 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13DB2A9F074 for ; Sun, 7 Feb 2016 05:58:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-2.reflexion.net [208.70.210.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 C921A75F for ; Sun, 7 Feb 2016 05:58:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25363 invoked from network); 7 Feb 2016 05:58:39 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 7 Feb 2016 05:58:39 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 07 Feb 2016 00:58:33 -0500 (EST) Received: (qmail 15689 invoked from network); 7 Feb 2016 05:58:32 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 7 Feb 2016 05:58:32 -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 X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id BB1CA1C43A8; Sat, 6 Feb 2016 21:58:18 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: powerpc (32-bit) clang 3.8.0 vs. gcc 4.2.1 routine preamble mismatches: contributions to SEGV's differences From: Mark Millard In-Reply-To: <3D08EB58-7FEF-432E-8192-77F988A75621@dsl-only.net> Date: Sat, 6 Feb 2016 21:58:24 -0800 Cc: Roman Divacky , Justin Hibbits , Konstantin Belousov , Nathan Whitehorn Content-Transfer-Encoding: quoted-printable Message-Id: References: <3D08EB58-7FEF-432E-8192-77F988A75621@dsl-only.net> To: FreeBSD PowerPC ML , FreeBSD Toolchain X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 05:58:33 -0000 I've submitted bug 206990 ( = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206990 ) with a = proof-of-concept patch for avoiding signal delivery mixed with clang = 3.8.0 generated code causing SEGV's --a patch that has passed my = personal testing so far. "make -j 6 buildworld" finished normally = instead of getting a SEGV in a few minutes on a = dual-processor/each-being-dual-core G5. Now a "make -j 3 buildworld" on a dual processor G4 is in process, = booted from the same SSD. We will see. The official TARGET_ARCH=3Dpowerpc sendsig code could tromp on the frame = pointer stored at "-4(r1)" (as seen in the clang3.8.0-generated code) = during the period in which the frame pointer is outside the range = identified by the stack pointer (r1) and where the stack started. The = change respects a Darwin-like/AIX-like "red-zone"/scratch area on the = smaller-address side of the stack. This should still be compatible with = gcc 4.2.1 style code, although it "wastes" more bytes temporarily in = that context. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-5, at 1:59 AM, Mark Millard wrote: >=20 > Clang 3.8.0 produced code uses r31 as a frame pointer in contexts = where gcc 4.2.1 produced code does not (ever?). This leaves clang's = produced code being more dependent on r31 handling, such as when = resuming after signal delivery. >=20 > The following is one of the routines in "make" where a clang 3.8.0 = based "make" sometimes gets a SEGV after resuming after a SIGCHLD = delivery, the SEGV being from having r31=3D0x0 in a Frame Pointer (r31) = based address calculation that is at some point dereferenced. (See = https://lists.freebsd.org/pipermail/freebsd-ppc/2016-February/008002.html = .) >=20 > But gcc 4.2.1 does not use r31 as a frame pointer in the Str_Match = that it produces and so does not see the problem. gcc 4.2.1's produced = code simply uses the stack pointer as needed. >=20 >=20 > clang 3.8.0 based Str_Match preamble (from make): >=20 > 0x181a4a8 : mflr r0 > 0x181a4ac : stw r31,-4(r1) # Clang's frame = pointer (r31)=20 > # saved before stack = pointer changed. > 0x181a4b0 : stw r0,4(r1) # lr saved before = stack pointer changed. > 0x181a4b4 : stwu r1,-32(r1) # Stack pointer = finally saved and > # changed. > 0x181a4b8 : mr r31,r1 # r31 is the frame = pointer under clang. > 0x181a4bc : stw r30,24(r31) >=20 > gcc 4.2.1 based Str_Match preamble: >=20 > 0x1819cb8 : mflr r0 > 0x1819cbc : stwu r1,-32(r1) # Stack pointer saved = and changed first. > 0x1819cc0 : stw r31,28(r1) # r31 saved after = stack pointer changed. > 0x1819cc4 : mr r31,r3 # gcc 4.2.1 does not = reserve > # r31 for use as a = frame pointer. > 0x1819cc8 : stw r30,24(r1) > 0x1819ccc : stw r0,36(r1) # lr saved after = stack pointer changed. >=20 >=20 > (Str_Match is a self contained routine, although it is recursive.) >=20 >=20 > Looking at some other gcc 4.2.1 preamble examples. . . >=20 > 0x1823b58 : cmpwi cr7,r6,0 > 0x1823b5c : stwu r1,-64(r1) # Stack pointer saved = and changed "first" > 0x1823b60 : mflr r0 > 0x1823b64 : lis r9,396 > 0x1823b68 : stw r25,36(r1) > 0x1823b6c : addi r25,r9,8944 > 0x1823b70 : stw r26,40(r1) > 0x1823b74 : mr r26,r3 > 0x1823b78 : stw r27,44(r1) > 0x1823b7c : mr r27,r4 > 0x1823b80 : stw r28,48(r1) > 0x1823b84 : mr r28,r8 > 0x1823b88 : stw r29,52(r1) > 0x1823b8c : mr r29,r5 > 0x1823b90 : stw r31,60(r1) > 0x1823b94 : mr r31,r7 # Again r31 is not a = frame pointer > 0x1823b98 : stw r0,68(r1) > 0x1823b9c : lwz r0,0(r25) > 0x1823ba0 : stw r0,28(r1) > 0x1823ba4 : li r0,0 > 0x1823ba8 : stw r30,56(r1) > 0x1823bac : beq- cr7,0x1823bbc >=20 >=20 > 0x1819f30 : mflr r0 # Stack pointer saved = and changed first > 0x1819f34 : stwu r1,-32(r1) > 0x1819f38 : stw r28,16(r1) > 0x1819f3c : mr r28,r5 > 0x1819f40 : stw r30,24(r1) > 0x1819f44 : mr r30,r3 > 0x1819f48 : stw r31,28(r1) > 0x1819f4c : mr r31,r4 # Again r31 is not a = frame pointer > 0x1819f50 : stw r29,20(r1) > 0x1819f54 : stw r0,36(r1) > 0x1819f58 : lbz r29,0(r4) >=20 >=20 > 0x181fcac : mflr r0 # Stack pointer saved = and changed first > 0x181fcb0 : stwu r1,-48(r1) > 0x181fcb4 : lis r9,396 > 0x181fcb8 : stw r27,28(r1) > 0x181fcbc : mr r27,r4 > 0x181fcc0 : stw r0,52(r1) > 0x181fcc4 : stw r28,32(r1) > 0x181fcc8 : mr r28,r7 > 0x181fccc : lwz r0,-1344(r9) > 0x181fcd0 : stw r29,36(r1) > 0x181fcd4 : mr r29,r5 > 0x181fcd8 : andi. r9,r0,512 > 0x181fcdc : stw r30,40(r1) > 0x181fce0 : stw r31,44(r1) > 0x181fce4 : mr r30,r8 > 0x181fce8 : mr r31,r6 # Again r31 is not a = frame pointer >=20 >=20 > 0x1801d58 : mflr r0 # Stack pointer saved = and changed first > 0x1801d5c : stwu r1,-48(r1) > 0x1801d60 : stw r28,32(r1) > 0x1801d64 : stw r0,52(r1) > 0x1801d68 : stw r30,40(r1) > 0x1801d6c : mr r30,r4 > 0x1801d70 : lwz r28,4(r3) > 0x1801d74 : lwz r4,0(r3) > 0x1801d78 : stw r29,36(r1) > 0x1801d7c : add r29,r30,r28 > 0x1801d80 : cmpw cr7,r29,r4 > 0x1801d84 : stw r27,28(r1) > 0x1801d88 : stw r31,44(r1) > 0x1801d8c : mr r27,r5 > 0x1801d90 : mr r31,r3 # Again r31 is not a = frame pointer >=20 >=20 > And so it goes for every intermittent SEGV related example (clang = 3.8.0 buildworld based) that I've examined: the matching gcc 4.2.1 code = would not try to use the the r31 values that clang does use. Instead gcc = 4.2.1 assigns an independent value to r31 before using it. >=20 >=20 > In effect gcc 4.2.1 and clang 3.8.0 are not following the exact-same = call standard. If clang 3.8.0's code generation is left as is then a = conversion to its call standard requirements will be required if clang = 3.8.0 is to be used for powerpc (32-bit). >=20 > "Works when gcc 4.2.1 is used" is not a great guide to "appropriate = for use with clang 3.8.0", at least in this area for powerpc (32-bit). >=20 > (These notes presume a context with sys/powerpc/powerpc/sigcode32.S = -r295186 in place so that signal delivery maintains the modulo 16 byte = stack/frame alignment status instead of changing the alignment. It = appears that, while necessary, this is not sufficient for a clang 3.8.0 = based buildworld to operate with signals reliably. See = https://lists.freebsd.org/pipermail/freebsd-ppc/2016-February/008002.html = .) >=20 > =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Feb 7 21:32:44 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F4F7AA0F65 for ; Sun, 7 Feb 2016 21:32:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-1.reflexion.net [208.70.210.1]) (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 16B501627 for ; Sun, 7 Feb 2016 21:32:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19413 invoked from network); 7 Feb 2016 21:32:51 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 7 Feb 2016 21:32:51 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 07 Feb 2016 16:32:32 -0500 (EST) Received: (qmail 3162 invoked from network); 7 Feb 2016 21:32:32 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 7 Feb 2016 21:32:32 -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 X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 01E831C43DC; Sun, 7 Feb 2016 13:32:32 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: powerpc (32-bit) clang 3.8.0 vs. gcc 4.2.1 routine preamble mismatches: contributions to SEGV's differences From: Mark Millard In-Reply-To: Date: Sun, 7 Feb 2016 13:32:36 -0800 Cc: Roman Divacky , Justin Hibbits , Konstantin Belousov , Nathan Whitehorn Content-Transfer-Encoding: quoted-printable Message-Id: <29B25F29-17DC-4F85-8C5A-3F286B260E29@dsl-only.net> References: <3D08EB58-7FEF-432E-8192-77F988A75621@dsl-only.net> To: FreeBSD PowerPC ML , FreeBSD Toolchain X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 21:32:44 -0000 On 2016-Feb-6, at 9:58 PM, Mark Millard wrote: >=20 > I've submitted bug 206990 ( = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206990 ) with a = proof-of-concept patch for avoiding signal delivery mixed with clang = 3.8.0 generated code causing SEGV's --a patch that has passed my = personal testing so far. "make -j 6 buildworld" finished normally = instead of getting a SEGV in a few minutes on a = dual-processor/each-being-dual-core G5. >=20 > Now a "make -j 3 buildworld" on a dual processor G4 is in process, = booted from the same SSD. We will see. >=20 > The official TARGET_ARCH=3Dpowerpc sendsig code could tromp on the = frame pointer stored at "-4(r1)" (as seen in the clang3.8.0-generated = code) during the period in which the frame pointer is outside the range = identified by the stack pointer (r1) and where the stack started. The = change respects a Darwin-like/AIX-like "red-zone"/scratch area on the = smaller-address side of the stack. This should still be compatible with = gcc 4.2.1 style code, although it "wastes" more bytes temporarily in = that context. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net Nathan Whitehorn had me submit to llvm.org. So there now is: Bug 26519 ( https://llvm.org/bugs/show_bug.cgi?id=3D26519 ) - Clang = 3.8.0's "Target: powerpc-unknown-freebsd11.0" code generation is = violating the ABI involved I left the "importance" at "normal" but if it still makes sense it may = be that "release blocker" would be appropriate. (Can 32-bit powerpc = block clang releases? Is it "too late now, already released"?) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-5, at 1:59 AM, Mark Millard wrote: >=20 > Clang 3.8.0 produced code uses r31 as a frame pointer in contexts = where gcc 4.2.1 produced code does not (ever?). This leaves clang's = produced code being more dependent on r31 handling, such as when = resuming after signal delivery. >=20 > The following is one of the routines in "make" where a clang 3.8.0 = based "make" sometimes gets a SEGV after resuming after a SIGCHLD = delivery, the SEGV being from having r31=3D0x0 in a Frame Pointer (r31) = based address calculation that is at some point dereferenced. (See = https://lists.freebsd.org/pipermail/freebsd-ppc/2016-February/008002.html = .) >=20 > But gcc 4.2.1 does not use r31 as a frame pointer in the Str_Match = that it produces and so does not see the problem. gcc 4.2.1's produced = code simply uses the stack pointer as needed. >=20 >=20 > clang 3.8.0 based Str_Match preamble (from make): >=20 > 0x181a4a8 : mflr r0 > 0x181a4ac : stw r31,-4(r1) # Clang's frame = pointer (r31)=20 > # saved before stack = pointer changed. > 0x181a4b0 : stw r0,4(r1) # lr saved before = stack pointer changed. > 0x181a4b4 : stwu r1,-32(r1) # Stack pointer = finally saved and > # changed. > 0x181a4b8 : mr r31,r1 # r31 is the frame = pointer under clang. > 0x181a4bc : stw r30,24(r31) >=20 > gcc 4.2.1 based Str_Match preamble: >=20 > 0x1819cb8 : mflr r0 > 0x1819cbc : stwu r1,-32(r1) # Stack pointer saved = and changed first. > 0x1819cc0 : stw r31,28(r1) # r31 saved after = stack pointer changed. > 0x1819cc4 : mr r31,r3 # gcc 4.2.1 does not = reserve > # r31 for use as a = frame pointer. > 0x1819cc8 : stw r30,24(r1) > 0x1819ccc : stw r0,36(r1) # lr saved after = stack pointer changed. >=20 >=20 > (Str_Match is a self contained routine, although it is recursive.) >=20 >=20 > Looking at some other gcc 4.2.1 preamble examples. . . >=20 > 0x1823b58 : cmpwi cr7,r6,0 > 0x1823b5c : stwu r1,-64(r1) # Stack pointer saved = and changed "first" > 0x1823b60 : mflr r0 > 0x1823b64 : lis r9,396 > 0x1823b68 : stw r25,36(r1) > 0x1823b6c : addi r25,r9,8944 > 0x1823b70 : stw r26,40(r1) > 0x1823b74 : mr r26,r3 > 0x1823b78 : stw r27,44(r1) > 0x1823b7c : mr r27,r4 > 0x1823b80 : stw r28,48(r1) > 0x1823b84 : mr r28,r8 > 0x1823b88 : stw r29,52(r1) > 0x1823b8c : mr r29,r5 > 0x1823b90 : stw r31,60(r1) > 0x1823b94 : mr r31,r7 # Again r31 is not a = frame pointer > 0x1823b98 : stw r0,68(r1) > 0x1823b9c : lwz r0,0(r25) > 0x1823ba0 : stw r0,28(r1) > 0x1823ba4 : li r0,0 > 0x1823ba8 : stw r30,56(r1) > 0x1823bac : beq- cr7,0x1823bbc >=20 >=20 > 0x1819f30 : mflr r0 # Stack pointer saved = and changed first > 0x1819f34 : stwu r1,-32(r1) > 0x1819f38 : stw r28,16(r1) > 0x1819f3c : mr r28,r5 > 0x1819f40 : stw r30,24(r1) > 0x1819f44 : mr r30,r3 > 0x1819f48 : stw r31,28(r1) > 0x1819f4c : mr r31,r4 # Again r31 is not a = frame pointer > 0x1819f50 : stw r29,20(r1) > 0x1819f54 : stw r0,36(r1) > 0x1819f58 : lbz r29,0(r4) >=20 >=20 > 0x181fcac : mflr r0 # Stack pointer saved = and changed first > 0x181fcb0 : stwu r1,-48(r1) > 0x181fcb4 : lis r9,396 > 0x181fcb8 : stw r27,28(r1) > 0x181fcbc : mr r27,r4 > 0x181fcc0 : stw r0,52(r1) > 0x181fcc4 : stw r28,32(r1) > 0x181fcc8 : mr r28,r7 > 0x181fccc : lwz r0,-1344(r9) > 0x181fcd0 : stw r29,36(r1) > 0x181fcd4 : mr r29,r5 > 0x181fcd8 : andi. r9,r0,512 > 0x181fcdc : stw r30,40(r1) > 0x181fce0 : stw r31,44(r1) > 0x181fce4 : mr r30,r8 > 0x181fce8 : mr r31,r6 # Again r31 is not a = frame pointer >=20 >=20 > 0x1801d58 : mflr r0 # Stack pointer saved = and changed first > 0x1801d5c : stwu r1,-48(r1) > 0x1801d60 : stw r28,32(r1) > 0x1801d64 : stw r0,52(r1) > 0x1801d68 : stw r30,40(r1) > 0x1801d6c : mr r30,r4 > 0x1801d70 : lwz r28,4(r3) > 0x1801d74 : lwz r4,0(r3) > 0x1801d78 : stw r29,36(r1) > 0x1801d7c : add r29,r30,r28 > 0x1801d80 : cmpw cr7,r29,r4 > 0x1801d84 : stw r27,28(r1) > 0x1801d88 : stw r31,44(r1) > 0x1801d8c : mr r27,r5 > 0x1801d90 : mr r31,r3 # Again r31 is not a = frame pointer >=20 >=20 > And so it goes for every intermittent SEGV related example (clang = 3.8.0 buildworld based) that I've examined: the matching gcc 4.2.1 code = would not try to use the the r31 values that clang does use. Instead gcc = 4.2.1 assigns an independent value to r31 before using it. >=20 >=20 > In effect gcc 4.2.1 and clang 3.8.0 are not following the exact-same = call standard. If clang 3.8.0's code generation is left as is then a = conversion to its call standard requirements will be required if clang = 3.8.0 is to be used for powerpc (32-bit). >=20 > "Works when gcc 4.2.1 is used" is not a great guide to "appropriate = for use with clang 3.8.0", at least in this area for powerpc (32-bit). >=20 > (These notes presume a context with sys/powerpc/powerpc/sigcode32.S = -r295186 in place so that signal delivery maintains the modulo 16 byte = stack/frame alignment status instead of changing the alignment. It = appears that, while necessary, this is not sufficient for a clang 3.8.0 = based buildworld to operate with signals reliably. See = https://lists.freebsd.org/pipermail/freebsd-ppc/2016-February/008002.html = .) >=20 > =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue Feb 9 11:28:32 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE5F0AA23D2 for ; Tue, 9 Feb 2016 11:28:32 +0000 (UTC) (envelope-from export@vascofilters.eu) Received: from karieraserlg.nazwa.pl (aju23.rev.netart.pl [77.55.254.23]) by mx1.freebsd.org (Postfix) with ESMTP id D3AFBC7B for ; Tue, 9 Feb 2016 11:28:31 +0000 (UTC) (envelope-from export@vascofilters.eu) Received: from pc (unknown [194.33.77.155]) by karieraserlg.nazwa.pl (Postfix) with ESMTPA id E532A3CE18C4 for ; Tue, 9 Feb 2016 12:28:30 +0100 (CET) From: "=?iso-8859-2?Q?Marcin_Tomzi=F1ski?=" To: "freebsd-ppc" Subject: cooperation Message-ID: Date: Tue, 9 Feb 2016 12:28:39 +0100 Organization: AnoMail - oprogramowanie do emailingow X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 11:28:32 -0000 =20 Are you looking for a new automotive parts brand to be different from your = competitors?=20 Do you want to be a direct importer?=20 Are you looking for high quality products at fair and individual quotation?= =20 Fed up with late deliveries and low availability from the stock?=20 Do you want to join young and effective organisation?=20 Do you need fast orders handling and flexibility in market approach? We have a great proposal for your business! =20 Our products range consists of more than 1500 references under 4 brands - VASCO FILTERS (oil, fuel air and cabin filters) - FLUXAR FILTERS (red line) - PEXA WIPERS (universal and dedicated sets of wipers) - BREYKO (brake pads)=20 We are expanding our business in your country and looking for direct import= ers.=20 Join our Team! More info on web page: www.vascofilters.com or facebook = =20 If you have any questions do not hesitate to contact us, we speak English, = French and Spanish. Marketing and Operations Manager Olaf Tomzi=F1ski If you do not wish to receive further information. From owner-freebsd-ppc@freebsd.org Wed Feb 10 19:31:03 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1A77AA4FF0 for ; Wed, 10 Feb 2016 19:31:03 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 5B2F2EEE for ; Wed, 10 Feb 2016 19:31:03 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: by mail-vk0-x235.google.com with SMTP id c3so21060891vkb.3 for ; Wed, 10 Feb 2016 11:31:03 -0800 (PST) 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 :content-type; bh=gfdtqIGi+niT8ZpD6Zzh8RBZ8OOAMY54sbo9xpFdmeU=; b=cIyHo1YgPm340tiAIl+L2R6bGoL/ZqSmrpU2ZbUb6XjhozuYIjpwDrXyTtrrK3ry2G XYhYvlMPCEdMSEwwLvhU5VKtnfxyq/3U15icgFsEBmby6MFoZ21CZz6w4KiJRhItBD7C vMaRvvRil4pIQLFKLRSw2wY+5odik9YR5uLzY9UH6znsP8GEuqzqfrAaZ+s26xAy2SNT VhGBkz++hGNr4jJ6wtgSKWKYekOQ/N9oF7W0c/HzfdhrfWNFjRwdr0Ezlo1OdUtaPlPV hyt2Vxr1hhuRO62tPKdrD2ZRILwie8MaBRTPLwIqhdQTf/BTlsJg0nRz+MB1E1VDq6bj PUKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=gfdtqIGi+niT8ZpD6Zzh8RBZ8OOAMY54sbo9xpFdmeU=; b=A4ievf2w3AIGwXIjnVWcw8Fxp6faT9VFHxWeTgG4x1N4KZrkNTZNLTmzpHDHP4gJgO oWDOkY3i/qLDWMj239zYBkZDxMDTd7OXzmnAq8XnWUNSP/tTcVGwtQcHDPTGl2EGCmvK Drku7MkTkjrnUqpanT0XoicrAglcuijN6l4741NAtkijlJ4927DHloY+BdbQy1lXEKTi Vl2peFyLY8B0R3Ns9j10eMqNLgTzhVwRCLX5uWJ2fzwuM+Qu8ZMkLlIdwZvmv6aht8D5 YBRkQdKFU8gBWBo4nEI5pm71e/QkHnAFWq/S9fHKyUhfkZ5k+BkKv8nQF2PIFnGhzBNI G8xg== X-Gm-Message-State: AG10YOSPKyJ5NkAupLEMsAVcmxcXF1X9A1bC1ZIclcmGzGX2Xms9P5ojTWREDq7gBelzj3lNZ2BrCwoOdBlbQw== MIME-Version: 1.0 X-Received: by 10.31.107.194 with SMTP id k63mr29042517vki.27.1455132662335; Wed, 10 Feb 2016 11:31:02 -0800 (PST) Received: by 10.103.37.196 with HTTP; Wed, 10 Feb 2016 11:31:02 -0800 (PST) In-Reply-To: <56BB8F42.9060005@raptorengineeringinc.com> References: <56BB8F42.9060005@raptorengineeringinc.com> Date: Wed, 10 Feb 2016 14:31:02 -0500 Message-ID: Subject: Fwd: An idea From: Joe Nosay To: FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 19:31:03 -0000 ---------- Forwarded message ---------- From: Raptor Engineeringing Sales Date: Wed, Feb 10, 2016 at 2:28 PM Subject: Re: An idea To: Joe Nosay On 02/10/2016 01:19 PM, Joe Nosay wrote: > Provide the buyers with a graphics and sound card. > Examples of sound card with > memory. https://en.wikipedia.org/wiki/E-mu_20K#Third_party or AMD True > Audio. > Also two graphics cards, with the second for complex formulas, i.e. NUMA > et al. > > Many thanks. This is something we would definitely like to be able to do, and we are working on the best way to balance the need for GPU performance with the requirement that the workstation ship without requiring closed source firmware blobs. As of this writing, the best way to handle the GPU situation appears to be to simply ensure that the ppc64el variants of Linux support both current AMD and nVidia cards < NVE0 (Kepler and below). nVidia has decided to prevent the use of Maxwell and above on non-x86/ARM systems by requiring signed firmware that cannot be used with the nouveau driver. The user can then decide which features are most important and select a graphics card from the supported list to purchase separately. The same issues do not exist with many high quality, modern sound cards, and therefore it may be possible to bundle an appropriate card with the Talos=E2=84=A2 workstation board. Thank you for your interest in the Talos=E2=84=A2 Secure Workstation, and b= e sure to let anyone else know who might be interested! -- Raptor Engineering Sales Phone: +1 (512) 690-0200 http://www.raptorengineeringinc.com From owner-freebsd-ppc@freebsd.org Thu Feb 11 10:54:37 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 56B1EAA506E for ; Thu, 11 Feb 2016 10:54:37 +0000 (UTC) (envelope-from export@vascofilters.eu) Received: from karieraserlg.nazwa.pl (aju23.rev.netart.pl [77.55.254.23]) by mx1.freebsd.org (Postfix) with ESMTP id 5CB9618E4 for ; Thu, 11 Feb 2016 10:54:36 +0000 (UTC) (envelope-from export@vascofilters.eu) Received: from pc (unknown [194.33.77.155]) by karieraserlg.nazwa.pl (Postfix) with ESMTPA id 63A4F3CE1A99 for ; Thu, 11 Feb 2016 11:54:35 +0100 (CET) From: "=?iso-8859-2?Q?Marcin_Tomzi=F1ski?=" To: "freebsd-ppc" Subject: cooperation Message-ID: <6985ADCC0FD942938FDBD81C97A2BFFD@pc> Date: Thu, 11 Feb 2016 11:54:38 +0100 Organization: AnoMail - oprogramowanie do emailingow X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 10:54:37 -0000 =20 Are you looking for a new automotive parts brand to be different from your = competitors?=20 Do you want to be a direct importer?=20 Are you looking for high quality products at fair and individual quotation?= =20 Fed up with late deliveries and low availability from the stock?=20 Do you want to join young and effective organisation?=20 Do you need fast orders handling and flexibility in market approach? We have a great proposal for your business! =20 Our products range consists of more than 1500 references under 4 brands - VASCO FILTERS (oil, fuel air and cabin filters) - FLUXAR FILTERS (red line) - PEXA WIPERS (universal and dedicated sets of wipers) - BREYKO (brake pads)=20 We are expanding our business in your country and looking for direct import= ers.=20 Join our Team! More info on web page: www.vascofilters.com or facebook = =20 If you have any questions do not hesitate to contact us, we speak English, = French and Spanish. Marketing and Operations Manager Olaf Tomzi=F1ski If you do not wish to receive further information. From owner-freebsd-ppc@freebsd.org Sat Feb 13 04:07:55 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BF9C3AA5F38 for ; Sat, 13 Feb 2016 04:07:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (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 756261FF9 for ; Sat, 13 Feb 2016 04:07:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26498 invoked from network); 13 Feb 2016 04:01:27 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 13 Feb 2016 04:01:27 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Fri, 12 Feb 2016 23:01:08 -0500 (EST) Received: (qmail 31555 invoked from network); 13 Feb 2016 04:01:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 13 Feb 2016 04:01:07 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7B7431C43B3; Fri, 12 Feb 2016 20:01:07 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: I have submitted bug 207147 for the wrong path to vm/uma_int.h being in use for buikldworld Message-Id: <03666B99-308C-4CFF-AF8C-5C6578361590@dsl-only.net> Date: Fri, 12 Feb 2016 20:01:12 -0800 To: glebius@FreeBSD.org, FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 04:07:55 -0000 I have submitted bug 207147: > powerpc 11.0-CURRENT -r295543: error: field 'uz_maxaction' has = incomplete type (blocking buildworld) for a "wrong header file (old) used in buildworld" sort of problem. The = submittal says in part (after applying my correction comment content to = the original wording): This traces back to the build using /usr/include instead of (in my = context) /usr/obj/gcc421/powerpc.powerpc/usr/src/tmp/usr/include and so = picking up an old vm/uma_int.h file. The detailed evidence follows. svnlite update -r295453 /usr/src (for an ^/head context) then a = buildworld buildkernel got: --- all_subdir_libmemstat --- --- memstat_uma.So --- cc -fpic -DPIC -g -O2 -pipe -MD -MP -MF.depend.memstat_uma.So = -MTmemstat_uma.So -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers = -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized = -Wno-pointer-sign -c /usr/src/lib/libmemstat/memstat_uma.c -o = memstat_uma.So . . . In file included from /usr/src/lib/libmemstat/memstat_uma.c:37: . . . --- all_subdir_libmemstat --- /usr/include/vm/uma_int.h:310: error: field 'uz_maxaction' has = incomplete type Note the "/usr/include" based path instead of a = /usr/obj/gcc421/powerpc.powerpc/usr/src/tmp/usr/include/vm/uma_int.h = path. Note the lack of any -I's or -isysroot's or such in the cc = command. Stop reading here unless you want more context details. src.conf content (make.conf empty): TO_TYPE=3Dpowerpc KERNCONF=3DGENERICvtsc-NODEBUG TARGET=3Dpowerpc .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif WITH_FAST_DEPEND=3D WITH_LIB32=3D WITH_BOOT=3D COMPILER_TYPE=3Dgcc WITHOUT_GCC_BOOTSTRAP=3D WITH_GCC=3D WITH_GCC_IS_CC=3D WITH_GNUCXX=3D WITHOUT_LIBCPLUSPLUS=3D WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D WITHOUT_CLANG_FULL=3D WITHOUT_CLANG_EXTRAS=3D NO_WERROR=3D MALLOC_PRODUCTION=3D WITH_DEBUG_FILES=3D # freebsd-version -ku; uname -aKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r295350M: Sat Feb = 6 13:54:57 PST 2016 = root@FBSDG4C0:/usr/obj/gcc421/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODE= BUG powerpc 1100097 1100097 Command used to buildworld buildkernel: env __MAKE_CONF=3D/root/src.configs/make.conf = SRC_ENV_CONF=3D/root/src.configs/src.conf.powerpc-gcc421.powerpc-host = MAKEOBJDIRPREFIX=3D/usr/obj/gcc421/powerpc.powerpc make -j 6 buildworld = buildkernel (This is a classic gcc 4.2.1 TARGET_ARCH=3Dpowerpc context, not a clang = 3.8.0 based experiment.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sat Feb 13 05:59:40 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 410C4AA5CFB for ; Sat, 13 Feb 2016 05:59:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-152.reflexion.net [208.70.211.152]) (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 E430D177B for ; Sat, 13 Feb 2016 05:59:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11598 invoked from network); 13 Feb 2016 05:59:36 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 13 Feb 2016 05:59:36 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sat, 13 Feb 2016 00:59:32 -0500 (EST) Received: (qmail 23886 invoked from network); 13 Feb 2016 05:59:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 13 Feb 2016 05:59:31 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id F30381C42A7; Fri, 12 Feb 2016 21:59:30 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: I've submitted bug 207148 for buildworld using the old /usr/include/sys/proc.h (so 'P_KPROC' undeclared) Message-Id: <6076DED9-14B4-4DC1-AB21-7C6CA8FF3CF6@dsl-only.net> Date: Fri, 12 Feb 2016 21:59:36 -0800 To: Konstantin Belousov , FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 05:59:40 -0000 A minor variation on what I wrote in the bug description is: This traces back to the build using /usr/include instead of (in my = context) /usr/obj/gcc421/powerpc.powerpc/usr/src/tmp/usr/include (or an = equivalent) and so picking up an old sys/proc.h file. The detailed = evidence follows. Note the lack of any -I or -isysroot or other such in = the cc command below. svnlite update -r295453 /usr/src (for an ^/head context) then a = buildworld buildkernel got: > --- all_subdir_bin --- > --- pkill.o --- > cc -O2 -pipe -g -MD -MP -MF.depend.pkill.o -MTpkill.o -std=3Dgnu99 = -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W = -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch = -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline = -Wnested-externs -Wredundant-decls -Wold-style-definition = -Wno-pointer-sign -c /usr/src/bin/pkill/pkill.c -o pkill.o > . . . > --- all_subdir_bin --- > /usr/src/bin/pkill/pkill.c: In function 'main': > /usr/src/bin/pkill/pkill.c:353: error: 'P_KPROC' undeclared (first use = in this function) > /usr/src/bin/pkill/pkill.c:353: error: (Each undeclared identifier is = reported only once > /usr/src/bin/pkill/pkill.c:353: error: for each function it appears = in.) > *** [pkill.o] Error code 1 >=20 > make[4]: stopped in /usr/src/bin/pkill > 1 error >=20 > make[4]: stopped in /usr/src/bin/pkill > *** [all_subdir_pkill] Error code 2 What is happening is: /usr/include/sys/proc.h still has P_KTHREAD (buildworld used this) /usr/obj/gcc421/powerpc.powerpc/usr/src/tmp/usr/include/sys/proc.h has = P_KPROC /usr/src/bin/pkill/Makefile has no CFLAGS+=3D SOMETHING_FOR_INCLUDE_PATH = . So it depends completely on context for directing where to find the = file for: > #include but that context ends up contributing nothing and so pure default path = rules are used --which picks up the still-old /usr/include/sys/proc.h = file. Stop reading here unless you want more context details. src.conf content (make.conf empty): > TO_TYPE=3Dpowerpc > KERNCONF=3DGENERICvtsc-NODEBUG > TARGET=3Dpowerpc > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > WITH_FAST_DEPEND=3D > WITH_LIB32=3D > WITH_BOOT=3D > COMPILER_TYPE=3Dgcc > WITHOUT_GCC_BOOTSTRAP=3D > WITH_GCC=3D > WITH_GCC_IS_CC=3D > WITH_GNUCXX=3D > WITHOUT_LIBCPLUSPLUS=3D > WITHOUT_CLANG_BOOTSTRAP=3D > WITHOUT_CLANG=3D > WITHOUT_CLANG_IS_CC=3D > WITHOUT_CLANG_FULL=3D > WITHOUT_CLANG_EXTRAS=3D > NO_WERROR=3D > MALLOC_PRODUCTION=3D > WITH_DEBUG_FILES=3D > # freebsd-version -ku; uname -aKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r295350M: Sat = Feb 6 13:54:57 PST 2016 = root@FBSDG4C0:/usr/obj/gcc421/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODE= BUG powerpc 1100097 1100097 Command used to buildworld buildkernel: > env __MAKE_CONF=3D/root/src.configs/make.conf = SRC_ENV_CONF=3D/root/src.configs/src.conf.powerpc-gcc421.powerpc-host = MAKEOBJDIRPREFIX=3D/usr/obj/gcc421/powerpc.powerpc make -j 6 buildworld = buildkernel (This is a classic self-hosted gcc 4.2.1 TARGET_ARCH=3Dpowerpc context, = not a clang 3.8.0 based experiment and not a cross build.) =3D=3D=3D Mark Millard markmi at dsl-only.net