From owner-freebsd-toolchain@freebsd.org Sun Aug 27 19:35:25 2017 Return-Path: Delivered-To: freebsd-toolchain@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 AC7D1DF6BB6 for ; Sun, 27 Aug 2017 19:35:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 9268D80528 for ; Sun, 27 Aug 2017 19:35:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v7RJZPnQ002497 for ; Sun, 27 Aug 2017 19:35:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 221864] clang 5.0 crashes on assert: "replacement types must always be canonical" Date: Sun, 27 Aug 2017 19:35:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status keywords bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 19:35:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221864 Bug ID: 221864 Summary: clang 5.0 crashes on assert: "replacement types must always be canonical" Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Keywords: needs-qa Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-toolchain@FreeBSD.org Reporter: jbeich@FreeBSD.org Created attachment 185824 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D185824&action= =3Dedit src/llvm_wrapper/llvm_wrapper.cpp (preprocessed, compressed) $ pkg install llvm40 cmake sdl2 git $ cd /tmp $ git clone https://github.com/programmerjake/vulkan-cpu $ cd vulkan-cpu $ cmake . $ make [...] [ 2%] Building CXX object src/llvm_wrapper/CMakeFiles/vulkan_cpu_llvm_wrapper.dir/llvm_wrapper.cpp.o cd /tmp/vulkan-cpu/src/llvm_wrapper && /usr/bin/CC=20=20 -I/usr/local/llvm40/include -I/tmp/vulkan-cpu/src -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Wall -ftemplate-depth=3D1024 -Werror "-Wno-error=3D#warnings" -std=3Dgnu++14 -o CMakeFiles/vulkan_cpu_llvm_wrapper.dir/llvm_wrapper.cpp.o -c /tmp/vulkan-cpu/src/llvm_wrapper/llvm_wrapper.cpp Assertion failed: (Replacement.isCanonical() && "replacement types must alw= ays be canonical"), function getSubstTemplateTypeParmType, file /poudriere/jails/head-amd64/usr/src/contrib/llvm/tools/clang/lib/AST/ASTCon= text.cpp, line 3520. c++: error: unable to execute command: Abort trap c++: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 5.0.0 (trunk 308421) (based on LLVM 5.0.0svn) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preproces= sed source, and associated run script. c++: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/llvm_wrapper-eb0531.cpp c++: note: diagnostic msg: /tmp/llvm_wrapper-eb0531.sh c++: note: diagnostic msg: ******************** *** Error code 254 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Aug 27 19:36:20 2017 Return-Path: Delivered-To: freebsd-toolchain@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 E198BDF6BF3 for ; Sun, 27 Aug 2017 19:36:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 CF7D98055F for ; Sun, 27 Aug 2017 19:36:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v7RJaKJ9003707 for ; Sun, 27 Aug 2017 19:36:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 221864] clang 5.0 crashes on assert: "replacement types must always be canonical" Date: Sun, 27 Aug 2017 19:36:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 19:36:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221864 --- Comment #1 from Jan Beich --- Created attachment 185825 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D185825&action= =3Dedit command line args (for clang 5.0) clang++40 from devel/llvm40 is not affected. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Aug 27 19:38:31 2017 Return-Path: Delivered-To: freebsd-toolchain@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 E1D01DF6C47 for ; Sun, 27 Aug 2017 19:38:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 CFAAC805DA for ; Sun, 27 Aug 2017 19:38:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v7RJcV50006680 for ; Sun, 27 Aug 2017 19:38:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 221864] clang 5.0 crashes on assert: "replacement types must always be canonical" Date: Sun, 27 Aug 2017 19:38:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 19:38:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221864 --- Comment #2 from Jan Beich --- I can still reproduce with more recent -CURRENT snapshot. $ c++ -v FreeBSD clang version 5.0.0 (branches/release_50 311606) (based on LLVM 5.0.0svn) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Aug 27 19:45:05 2017 Return-Path: Delivered-To: freebsd-toolchain@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 A28E2DF6F2A for ; Sun, 27 Aug 2017 19:45:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 90CCB80AAB for ; Sun, 27 Aug 2017 19:45:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v7RJj572025212 for ; Sun, 27 Aug 2017 19:45:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 221864] clang 5.0 crashes on assert: "replacement types must always be canonical" Date: Sun, 27 Aug 2017 19:45:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 19:45:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221864 --- Comment #3 from Jan Beich --- Given devel/llvm50 port is still missing (-devel snapshot is too old to be = of any use) I can't check if the issue is due to libLLVM and Clang mismatch. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Aug 27 20:58:52 2017 Return-Path: Delivered-To: freebsd-toolchain@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 5E458DF7FB5 for ; Sun, 27 Aug 2017 20:58:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 4C3B8825A3 for ; Sun, 27 Aug 2017 20:58:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v7RKwpjD011938 for ; Sun, 27 Aug 2017 20:58:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 221864] clang 5.0 crashes on assert: "replacement types must always be canonical" Date: Sun, 27 Aug 2017 20:58:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 20:58:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221864 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress Assignee|freebsd-toolchain@FreeBSD.o |dim@FreeBSD.org |rg | CC| |dim@FreeBSD.org, | |emaste@freebsd.org --- Comment #4 from Dimitry Andric --- This also reproduces with upstream trunk r311836. I'll bisect and/or minim= ize. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Aug 29 09:39:13 2017 Return-Path: Delivered-To: freebsd-toolchain@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 D8FBBDD4962 for ; Tue, 29 Aug 2017 09:39:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 C76E47ECBB for ; Tue, 29 Aug 2017 09:39:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v7T9dBX6024521 for ; Tue, 29 Aug 2017 09:39:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 221733] SSE2 instructions emited in compiler-rt on AMD Sempron 3000+ Date: Tue, 29 Aug 2017 09:39:12 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: bsdpr@phoe.frmug.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 09:39:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221733 --- Comment #5 from bsdpr@phoe.frmug.org --- Created attachment 185862 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D185862&action= =3Dedit Patch reverting to C implementations on i386 This patch, on i386, reverts to the C implementations of the functions affe= cted by the unguarded use of SSE2 instructions in the assembler implementations. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Aug 29 09:43:23 2017 Return-Path: Delivered-To: freebsd-toolchain@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 1AB93DD4BA4 for ; Tue, 29 Aug 2017 09:43:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 08A437EF7B for ; Tue, 29 Aug 2017 09:43:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v7T9hMKo039970 for ; Tue, 29 Aug 2017 09:43:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 221733] SSE2 instructions emited in compiler-rt on AMD Sempron 3000+ Date: Tue, 29 Aug 2017 09:43:23 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: bsdpr@phoe.frmug.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 09:43:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221733 --- Comment #6 from bsdpr@phoe.frmug.org --- Here is a na=C3=AFve patch that use the C implementation of the affected fu= nctions. After buildworld and installworld: $ objdump -d /usr/lib/libcompiler_rt.a | grep -c xmm 0 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Aug 29 10:10:27 2017 Return-Path: Delivered-To: freebsd-toolchain@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 1C2ECDD53AC for ; Tue, 29 Aug 2017 10:10:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 0A2C97F934 for ; Tue, 29 Aug 2017 10:10:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v7TAAQiI020807 for ; Tue, 29 Aug 2017 10:10:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 221733] SSE2 instructions emited in compiler-rt on AMD Sempron 3000+ Date: Tue, 29 Aug 2017 10:10:27 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.3-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 10:10:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221733 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Aug 29 19:59:00 2017 Return-Path: Delivered-To: freebsd-toolchain@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 3DD59DE43CB for ; Tue, 29 Aug 2017 19:59:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-93.reflexion.net [208.70.210.93]) (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 E2E166F15E for ; Tue, 29 Aug 2017 19:58:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26847 invoked from network); 29 Aug 2017 19:52:18 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Aug 2017 19:52:18 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Tue, 29 Aug 2017 15:52:18 -0400 (EDT) Received: (qmail 9496 invoked from network); 29 Aug 2017 19:52:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Aug 2017 19:52:18 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 9B23CEC936E; Tue, 29 Aug 2017 12:52:17 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: stable/11 -r322591 using WITH_LLD_IS_LD= : delete-old removes . . ./usr/bin/ld Message-Id: <660AE7B2-AB5D-4D8A-9359-3D08BE6DAB7E@dsl-only.net> Date: Tue, 29 Aug 2017 12:52:16 -0700 To: FreeBSD Toolchain , freebsd-arm X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 19:59:00 -0000 In some build experiments for amd64 -> aarch64 cross builds/local-file-system-installs for stable/11 -r322591 with WITH_LLD_IS_LD=3D I got examples of delete-old delete-old-libs deleting the path to ld after a from-scratch build: >>> Removing old files (only deletes safe to delete libs) = /usr/obj/DESTDIRs/clang-cortexA53-installworld-dist-from-src/usr/share/man= /man4/hv_vss.4.gz /usr/obj/DESTDIRs/clang-cortexA53-installworld-dist-from-src/usr/bin/ld >>> Old files removed >>> Removing old directories = /usr/obj/DESTDIRs/clang-cortexA53-installworld-dist-from-src/usr/lib/debug= /usr/lib/private >>> Old directories removed To remove old libraries run 'make delete-old-libs'. >>> Removing old libraries Please be sure no application still uses those libraries, else you can not start such an application. Consult UPDATING for more information regarding how to cope with the removal/revision bump of a specific library. >>> Old libraries removed # ls -lT = /usr/obj/DESTDIRs/clang-cortexA53-installworld-dist-from-src/usr/bin/*ld* -r-xr-xr-x 1 root wheel 200056 Aug 29 11:40:10 2017 = /usr/obj/DESTDIRs/clang-cortexA53-installworld-dist-from-src/usr/bin/colld= ef -r-xr-xr-x 1 root wheel 199968 Aug 29 11:40:12 2017 = /usr/obj/DESTDIRs/clang-cortexA53-installworld-dist-from-src/usr/bin/fold -r-xr-xr-x 1 root wheel 25171560 Aug 29 11:40:16 2017 = /usr/obj/DESTDIRs/clang-cortexA53-installworld-dist-from-src/usr/bin/ld.ll= d -r-xr-xr-x 1 root wheel 199760 Aug 29 11:40:13 2017 = /usr/obj/DESTDIRs/clang-cortexA53-installworld-dist-from-src/usr/bin/ldd -r-xr-xr-x 1 root wheel 40441008 Aug 29 11:40:16 2017 = /usr/obj/DESTDIRs/clang-cortexA53-installworld-dist-from-src/usr/bin/lldb -r-xr-xr-x 1 root wheel 7802624 Aug 29 11:40:15 2017 = /usr/obj/DESTDIRs/clang-cortexA53-installworld-dist-from-src/usr/bin/llvm-= rtdyld So no hard or symbolic link pointing to ld.lld . Context details: # svnlite info /usr/src/ | grep "Re[plv]" Relative URL: ^/stable/11 Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 322591 Last Changed Rev: 322591 # more ~/src.configs/src.conf.cortexA53-clang-bootstrap.amd64-host TO_TYPE=3Daarch64 TOOLS_TO_TYPE=3D${TO_TYPE} # KERNCONF=3DGENERIC-NODBG TARGET=3Darm64 .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD_BOOTSTRAP=3D WITH_LLD=3D WITH_LLD_IS_LD=3D WITH_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # #CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ XCFLAGS+=3D -mcpu=3Dcortex-a53 XCXXFLAGS+=3D -mcpu=3Dcortex-a53 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. # more /usr/src/sys/arm64/conf/GENERIC-NODBG=20 # # GENERIC -- Custom configuration for the arm64/aarch64 # include "GENERIC" ident GENERIC-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: #options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones nooptions BUF_TRACKING =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Tue Aug 29 21:35:24 2017 Return-Path: Delivered-To: freebsd-toolchain@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 83FCDDE64CA for ; Tue, 29 Aug 2017 21:35:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-93.reflexion.net [208.70.210.93]) (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 39EAA720DA for ; Tue, 29 Aug 2017 21:35:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25889 invoked from network); 29 Aug 2017 21:35:22 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 29 Aug 2017 21:35:22 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Tue, 29 Aug 2017 17:35:22 -0400 (EDT) Received: (qmail 16716 invoked from network); 29 Aug 2017 21:35:22 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Aug 2017 21:35:22 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 61871EC93AB; Tue, 29 Aug 2017 14:35:21 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: poudriere's -x (build_native_tools) vs. use of "-m null" : how to enable it Message-Id: <9B2F4539-AAA9-45EB-AC92-F47E9CAA21FF@dsl-only.net> Date: Tue, 29 Aug 2017 14:35:20 -0700 To: Bryan Drewery , FreeBSD Toolchain X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 21:35:24 -0000 In a command command such as: poudriere jail -c -j zrFBSDx64SLppc64 -a powerpc.powerpc64 -x -m null -M = /usr/obj/DESTDIRs/clang-powerpc64-altbinutils-installworld-dist-from-src = -S /usr/src/ -v 11.1-STABLE the -x is silently ignored. I added the "build_native_xtools" into the /usr/local/share/poudriere/jail.sh code to have it contain: null) JAILFS=3Dnone FCT=3Dbuild_native_xtools ;; in order to avoid this. A similar "jail -c" for "-j zrFBSDx64SLarmv7 -a arm.armv6" (and -M /usr/obj/DESTDIRs/clang-armv7-installworld-dist-from-src=20 in my context) and the later bulk build for it seems to be working fine for building lang/gcc7 (as a test). So far: [00:00:16] [01] [00:00:00] Building ports-mgmt/pkg | pkg-1.10.1 [00:01:02] [01] [00:00:46] Finished ports-mgmt/pkg | pkg-1.10.1: Success [00:01:03] [01] [00:00:00] Building print/indexinfo | indexinfo-0.2.6 [00:01:03] [02] [00:00:00] Building lang/perl5.24 | perl5-5.24.2 [00:01:06] [01] [00:00:03] Finished print/indexinfo | indexinfo-0.2.6: = Success [00:01:06] [01] [00:00:00] Building devel/gettext-runtime | = gettext-runtime-0.19.8.1_1 [00:01:35] [01] [00:00:29] Finished devel/gettext-runtime | = gettext-runtime-0.19.8.1_1: Success [00:01:35] [01] [00:00:00] Building devel/gettext-tools | = gettext-tools-0.19.8.1 ^C[00:03:18] Error: Signal SIGINT caught, cleaning up and exiting [00:03:18] Cleaning up [00:00:10] [01] [00:00:00] Building devel/gettext-tools | = gettext-tools-0.19.8.1 [00:00:10] [02] [00:00:00] Building lang/perl5.24 | perl5-5.24.2 [00:02:12] [01] [00:02:02] Finished devel/gettext-tools | = gettext-tools-0.19.8.1: Success [00:02:13] [01] [00:00:00] Building devel/gmake | gmake-4.2.1_1 [00:02:54] [01] [00:00:41] Finished devel/gmake | gmake-4.2.1_1: Success [00:12:44] [02] [00:12:34] Finished lang/perl5.24 | perl5-5.24.2: = Success [00:12:44] [01] [00:00:00] Building devel/p5-Locale-gettext | = p5-Locale-gettext-1.07 [00:13:13] [01] [00:00:29] Finished devel/p5-Locale-gettext | = p5-Locale-gettext-1.07: Success [00:13:14] [01] [00:00:00] Building misc/help2man | help2man-1.47.4 [00:13:37] [01] [00:00:23] Finished misc/help2man | help2man-1.47.4: = Success [00:13:37] [01] [00:00:00] Building print/texinfo | texinfo-6.4_1,1 ^C[00:14:43] Error: Signal SIGINT caught, cleaning up and exiting [00:14:43] Cleaning up [00:00:17] [01] [00:00:00] Building print/texinfo | texinfo-6.4_1,1 [00:03:03] [01] [00:02:46] Finished print/texinfo | texinfo-6.4_1,1: = Success [00:03:03] [01] [00:00:00] Building math/gmp | gmp-6.1.2 [00:03:03] [02] [00:00:00] Building devel/m4 | m4-1.4.18,1 [00:04:02] [02] [00:00:59] Finished devel/m4 | m4-1.4.18,1: Success [00:04:03] [02] [00:00:00] Building devel/bison | bison-3.0.4,1 [00:04:28] [01] [00:01:25] Finished math/gmp | gmp-6.1.2: Success [00:04:28] [01] [00:00:00] Building math/mpfr | mpfr-3.1.5_1 [00:04:45] [02] [00:00:42] Finished devel/bison | bison-3.0.4,1: Success [00:04:48] [01] [00:00:20] Finished math/mpfr | mpfr-3.1.5_1: Success [00:04:48] [01] [00:00:00] Building devel/binutils | binutils-2.28,1 [00:04:48] [02] [00:00:00] Building math/mpc | mpc-1.0.3 [00:05:00] [02] [00:00:12] Finished math/mpc | mpc-1.0.3: Success [00:20:29] [01] [00:15:41] Finished devel/binutils | binutils-2.28,1: = Success [00:20:30] [01] [00:00:00] Building lang/gcc7 | gcc7-7.2.0 So I expect that the change is appropriate. [Unfortunately qemu-ppc64-static seems to not work: the qemu-ppc64-static process just sits and eats CPU time with increasing SIZE when qemu-ppc64-static is put to use via poudriere. This blocks progress.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Tue Aug 29 21:38:52 2017 Return-Path: Delivered-To: freebsd-toolchain@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 68F71DE6562 for ; Tue, 29 Aug 2017 21:38:52 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3ABAC721A0; Tue, 29 Aug 2017 21:38:52 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 6DBD1155F3; Tue, 29 Aug 2017 21:38:51 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 408CD8258; Tue, 29 Aug 2017 21:38:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id ShtCS_KKd27o; Tue, 29 Aug 2017 21:38:46 +0000 (UTC) Subject: Re: poudriere's -x (build_native_tools) vs. use of "-m null" : how to enable it DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 140CE8243 To: Mark Millard , FreeBSD Toolchain References: <9B2F4539-AAA9-45EB-AC92-F47E9CAA21FF@dsl-only.net> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: Date: Tue, 29 Aug 2017 14:38:29 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <9B2F4539-AAA9-45EB-AC92-F47E9CAA21FF@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IO4lchBjrFOB53hU0vRvDemFHwDOeM2k9" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 21:38:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IO4lchBjrFOB53hU0vRvDemFHwDOeM2k9 Content-Type: multipart/mixed; boundary="I2i0DfPD8jxO6Bn86WaXh7rnNTPlceh1a"; protected-headers="v1" From: Bryan Drewery To: Mark Millard , FreeBSD Toolchain Message-ID: Subject: Re: poudriere's -x (build_native_tools) vs. use of "-m null" : how to enable it References: <9B2F4539-AAA9-45EB-AC92-F47E9CAA21FF@dsl-only.net> In-Reply-To: <9B2F4539-AAA9-45EB-AC92-F47E9CAA21FF@dsl-only.net> --I2i0DfPD8jxO6Bn86WaXh7rnNTPlceh1a Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 8/29/2017 2:35 PM, Mark Millard wrote: > In a command command such as: >=20 > poudriere jail -c -j zrFBSDx64SLppc64 -a powerpc.powerpc64 -x -m null -= M /usr/obj/DESTDIRs/clang-powerpc64-altbinutils-installworld-dist-from-sr= c -S /usr/src/ -v 11.1-STABLE >=20 > the -x is silently ignored. I added the "build_native_xtools" into > the /usr/local/share/poudriere/jail.sh code to have it contain: I consider '-m null' to be a read-only operation on the provided path. Poudriere did not build it, so I would rather not force a build procedure on it for native-xtools either. On the otherhand, if we store the native-xtools files outside of the jail path then it will not be a problem. >=20 > null) > JAILFS=3Dnone > FCT=3Dbuild_native_xtools > ;; >=20 > in order to avoid this. >=20 > A similar "jail -c" for "-j zrFBSDx64SLarmv7 -a arm.armv6" (and > -M /usr/obj/DESTDIRs/clang-armv7-installworld-dist-from-src=20 > in my context) and the later bulk build for it seems to be > working fine for building lang/gcc7 (as a test). So far: >=20 > [00:00:16] [01] [00:00:00] Building ports-mgmt/pkg | pkg-1.10.1 > [00:01:02] [01] [00:00:46] Finished ports-mgmt/pkg | pkg-1.10.1: Succes= s > [00:01:03] [01] [00:00:00] Building print/indexinfo | indexinfo-0.2.6 > [00:01:03] [02] [00:00:00] Building lang/perl5.24 | perl5-5.24.2 > [00:01:06] [01] [00:00:03] Finished print/indexinfo | indexinfo-0.2.6: = Success > [00:01:06] [01] [00:00:00] Building devel/gettext-runtime | gettext-run= time-0.19.8.1_1 > [00:01:35] [01] [00:00:29] Finished devel/gettext-runtime | gettext-run= time-0.19.8.1_1: Success > [00:01:35] [01] [00:00:00] Building devel/gettext-tools | gettext-tools= -0.19.8.1 > ^C[00:03:18] Error: Signal SIGINT caught, cleaning up and exiting > [00:03:18] Cleaning up >=20 > [00:00:10] [01] [00:00:00] Building devel/gettext-tools | gettext-tools= -0.19.8.1 > [00:00:10] [02] [00:00:00] Building lang/perl5.24 | perl5-5.24.2 > [00:02:12] [01] [00:02:02] Finished devel/gettext-tools | gettext-tools= -0.19.8.1: Success > [00:02:13] [01] [00:00:00] Building devel/gmake | gmake-4.2.1_1 > [00:02:54] [01] [00:00:41] Finished devel/gmake | gmake-4.2.1_1: Succes= s > [00:12:44] [02] [00:12:34] Finished lang/perl5.24 | perl5-5.24.2: Succe= ss > [00:12:44] [01] [00:00:00] Building devel/p5-Locale-gettext | p5-Locale= -gettext-1.07 > [00:13:13] [01] [00:00:29] Finished devel/p5-Locale-gettext | p5-Locale= -gettext-1.07: Success > [00:13:14] [01] [00:00:00] Building misc/help2man | help2man-1.47.4 > [00:13:37] [01] [00:00:23] Finished misc/help2man | help2man-1.47.4: Su= ccess > [00:13:37] [01] [00:00:00] Building print/texinfo | texinfo-6.4_1,1 > ^C[00:14:43] Error: Signal SIGINT caught, cleaning up and exiting > [00:14:43] Cleaning up >=20 > [00:00:17] [01] [00:00:00] Building print/texinfo | texinfo-6.4_1,1 > [00:03:03] [01] [00:02:46] Finished print/texinfo | texinfo-6.4_1,1: Su= ccess > [00:03:03] [01] [00:00:00] Building math/gmp | gmp-6.1.2 > [00:03:03] [02] [00:00:00] Building devel/m4 | m4-1.4.18,1 > [00:04:02] [02] [00:00:59] Finished devel/m4 | m4-1.4.18,1: Success > [00:04:03] [02] [00:00:00] Building devel/bison | bison-3.0.4,1 > [00:04:28] [01] [00:01:25] Finished math/gmp | gmp-6.1.2: Success > [00:04:28] [01] [00:00:00] Building math/mpfr | mpfr-3.1.5_1 > [00:04:45] [02] [00:00:42] Finished devel/bison | bison-3.0.4,1: Succes= s > [00:04:48] [01] [00:00:20] Finished math/mpfr | mpfr-3.1.5_1: Success > [00:04:48] [01] [00:00:00] Building devel/binutils | binutils-2.28,1 > [00:04:48] [02] [00:00:00] Building math/mpc | mpc-1.0.3 > [00:05:00] [02] [00:00:12] Finished math/mpc | mpc-1.0.3: Success > [00:20:29] [01] [00:15:41] Finished devel/binutils | binutils-2.28,1: S= uccess > [00:20:30] [01] [00:00:00] Building lang/gcc7 | gcc7-7.2.0 >=20 > So I expect that the change is appropriate. >=20 >=20 > [Unfortunately qemu-ppc64-static seems to not work: > the qemu-ppc64-static process just sits and eats CPU time > with increasing SIZE when qemu-ppc64-static is put to use > via poudriere. This blocks progress.] >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 --=20 Regards, Bryan Drewery --I2i0DfPD8jxO6Bn86WaXh7rnNTPlceh1a-- --IO4lchBjrFOB53hU0vRvDemFHwDOeM2k9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJZpd7VAAoJEDXXcbtuRpfP8hkIAKH9MlR299qHCxjiL2uty3h/ NZIvZaLn16w77WPRGNVoSRIJJFEMEvFYcXh/o73Scz3+dvpn4SzmtulHvR/IZDZB 7kgG8z0Y5iWKOHXBePY8OYy/zIKMS317RCSuOPK74QY4RL6tEeVMQM2eQ0fE/GNL kZ90UvwtwUSpB/21GrqQ9kEguPVmI2GWPl8WDdTzbSuPz/us0kv7XPtOoNFoPrRD WlIdRgYzBpVPHqO8ZIpZtQF16nD24TfiksvGsTlpyJoJ2JSXJy7BuVQfO7OUurmz oxkmiP6ZazJOGfbVJUw8ovTIFdy+pwOJRJnYxey69qFOfJlUHAvvfVAfiJJDACY= =89U1 -----END PGP SIGNATURE----- --IO4lchBjrFOB53hU0vRvDemFHwDOeM2k9-- From owner-freebsd-toolchain@freebsd.org Tue Aug 29 21:45:53 2017 Return-Path: Delivered-To: freebsd-toolchain@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 A0D69DE6816 for ; Tue, 29 Aug 2017 21:45:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 8EED972616 for ; Tue, 29 Aug 2017 21:45:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v7TLjpGj029286 for ; Tue, 29 Aug 2017 21:45:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 221733] SSE2 instructions emited in compiler-rt on AMD Sempron 3000+ Date: Tue, 29 Aug 2017 21:45:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.3-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 21:45:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221733 --- Comment #7 from commit-hook@freebsd.org --- A commit references this bug: Author: dim Date: Tue Aug 29 21:45:00 UTC 2017 New revision: 323001 URL: https://svnweb.freebsd.org/changeset/base/323001 Log: In compiler-rt, a few assembler implementations for i386 floating point conversion functions use SSE2 instructions, but these are not guarded by #ifdef __SSE2__, and there is no implementation using general purpose registers. For these functions, use the generic C variants instead, otherwise they will cause SIGILL on older processors. Reported by: bsdpr@phoe.frmug.org PR: 221733 MFC after: 1 week Changes: head/lib/libcompiler_rt/Makefile.inc --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Aug 29 21:47:30 2017 Return-Path: Delivered-To: freebsd-toolchain@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 C8CA6DE6880 for ; Tue, 29 Aug 2017 21:47:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 B644E72683 for ; Tue, 29 Aug 2017 21:47:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v7TLlUqV031421 for ; Tue, 29 Aug 2017 21:47:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 221733] SSE2 instructions emited in compiler-rt on AMD Sempron 3000+ Date: Tue, 29 Aug 2017 21:47:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.3-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: mfc-stable9+ mfc-stable10+ mfc-stable11+ X-Bugzilla-Changed-Fields: bug_severity assigned_to flagtypes.name bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 21:47:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221733 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Affects Only Me |Affects Some People Assignee|freebsd-toolchain@FreeBSD.o |dim@FreeBSD.org |rg | Flags| |mfc-stable9+, | |mfc-stable10+, | |mfc-stable11+ Status|Open |In Progress --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Aug 29 22:08:16 2017 Return-Path: Delivered-To: freebsd-toolchain@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 1E134DE6DFD for ; Tue, 29 Aug 2017 22:08:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-94.reflexion.net [208.70.210.94]) (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 BEFBD72DBD for ; Tue, 29 Aug 2017 22:08:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26051 invoked from network); 29 Aug 2017 22:08:14 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 29 Aug 2017 22:08:14 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Tue, 29 Aug 2017 18:08:14 -0400 (EDT) Received: (qmail 31748 invoked from network); 29 Aug 2017 22:08:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Aug 2017 22:08:13 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 47E83EC94BD; Tue, 29 Aug 2017 15:08:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: poudriere's -x (build_native_tools) vs. use of "-m null" : how to enable it From: Mark Millard In-Reply-To: Date: Tue, 29 Aug 2017 15:08:12 -0700 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <52C6B6AA-EAAD-41A1-A07F-C773D9F33315@dsl-only.net> References: <9B2F4539-AAA9-45EB-AC92-F47E9CAA21FF@dsl-only.net> To: Bryan Drewery X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 22:08:16 -0000 On 2017-Aug-29, at 2:38 PM, Bryan Drewery wrote: > On 8/29/2017 2:35 PM, Mark Millard wrote: >> In a command command such as: >>=20 >> poudriere jail -c -j zrFBSDx64SLppc64 -a powerpc.powerpc64 -x -m null = -M = /usr/obj/DESTDIRs/clang-powerpc64-altbinutils-installworld-dist-from-src = -S /usr/src/ -v 11.1-STABLE >>=20 >> the -x is silently ignored. I added the "build_native_xtools" into >> the /usr/local/share/poudriere/jail.sh code to have it contain: >=20 > I consider '-m null' to be a read-only operation on the provided path. > Poudriere did not build it, so I would rather not force a build > procedure on it for native-xtools either. >=20 > On the otherhand, if we store the native-xtools files outside of the > jail path then it will not be a problem. Okay. I was just looking for a way to deal with local experimental patches in the system and/or ports rather than building from official materials, checking how things seem to go for builds. I ended up with the following nxb* directories in /usr/obj/. . . for my context: /usr/obj/powerpc.powerpc/nxb /usr/obj/arm.armv6/nxb /usr/obj/arm64.aarch64/nxb /usr/obj/DESTDIRs/clang-armv7-installworld-dist-from-src/nxb-bin /usr/obj/DESTDIRs/clang-cortexA53-installworld-dist-from-src/nxb-bin /usr/obj/DESTDIRs/gcc421-powerpc-installworld-dist-from-src/nxb-bin /usr/obj/DESTDIRs/clang-powerpc-installworld-dist-from-src/nxb-bin = /usr/obj/DESTDIRs/clang-powerpc64-altbinutils-installworld-dist-from-src/n= xb-bin /usr/obj/DESTDIRs/clang-cortexA57-installworld-dist-from-src/nxb-bin /usr/obj/powerpc.powerpc64/nxb However, for example, I did the powerpc ones in the order (as an experiment that I did not expect to "work"): /usr/obj/DESTDIRs/clang-powerpc-installworld-dist-from-src/nxb-bin /usr/obj/DESTDIRs/gcc421-powerpc-installworld-dist-from-src/nxb-bin and the second reused the material from the first -x . In other words: the native compiler ended up being based on clang for the later gcc421 based jail attempt. A similar point goes for the pair (in order): /usr/obj/DESTDIRs/clang-cortexA53-installworld-dist-from-src/nxb-bin /usr/obj/DESTDIRs/clang-cortexA57-installworld-dist-from-src/nxb-bin in that the A57 one bound to the prior A53 -x content. I'm not claiming a problem, just something to know to expect to avoid. (My 32-bit powerpc activity has lead to building things based on both compilers because of the kernel build only working for gcc421-based builds. Such odd combinations are likely rare.) >>=20 >> null) >> JAILFS=3Dnone >> FCT=3Dbuild_native_xtools >> ;; >>=20 >> in order to avoid this. >>=20 >> A similar "jail -c" for "-j zrFBSDx64SLarmv7 -a arm.armv6" (and >> -M /usr/obj/DESTDIRs/clang-armv7-installworld-dist-from-src=20 >> in my context) and the later bulk build for it seems to be >> working fine for building lang/gcc7 (as a test). So far: . . . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Tue Aug 29 22:29:32 2017 Return-Path: Delivered-To: freebsd-toolchain@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 D6551DE7490 for ; Tue, 29 Aug 2017 22:29:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-93.reflexion.net [208.70.210.93]) (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 8C03E73864 for ; Tue, 29 Aug 2017 22:29:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23595 invoked from network); 29 Aug 2017 22:29:31 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Aug 2017 22:29:31 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Tue, 29 Aug 2017 18:29:31 -0400 (EDT) Received: (qmail 10316 invoked from network); 29 Aug 2017 22:29:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Aug 2017 22:29:30 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 44155EC94A0; Tue, 29 Aug 2017 15:29:30 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: poudriere's -x (build_native_tools) vs. use of "-m null" : how to enable it Date: Tue, 29 Aug 2017 15:29:29 -0700 References: <9B2F4539-AAA9-45EB-AC92-F47E9CAA21FF@dsl-only.net> <52C6B6AA-EAAD-41A1-A07F-C773D9F33315@dsl-only.net> To: Bryan Drewery , FreeBSD Toolchain In-Reply-To: <52C6B6AA-EAAD-41A1-A07F-C773D9F33315@dsl-only.net> Message-Id: <2A6F3F8A-2957-477D-8AD5-B0494598F7F8@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 22:29:33 -0000 On 2017-Aug-29, at 3:08 PM, Mark Millard wrote: > On 2017-Aug-29, at 2:38 PM, Bryan Drewery = wrote: >=20 >> On 8/29/2017 2:35 PM, Mark Millard wrote: >>> In a command command such as: >>>=20 >>> poudriere jail -c -j zrFBSDx64SLppc64 -a powerpc.powerpc64 -x -m = null -M = /usr/obj/DESTDIRs/clang-powerpc64-altbinutils-installworld-dist-from-src = -S /usr/src/ -v 11.1-STABLE >>>=20 >>> the -x is silently ignored. I added the "build_native_xtools" into >>> the /usr/local/share/poudriere/jail.sh code to have it contain: >>=20 >> I consider '-m null' to be a read-only operation on the provided = path. >> Poudriere did not build it, so I would rather not force a build >> procedure on it for native-xtools either. >>=20 >> On the otherhand, if we store the native-xtools files outside of the >> jail path then it will not be a problem. >=20 > Okay. I was just looking for a way to deal with local > experimental patches in the system and/or ports rather > than building from official materials, checking how > things seem to go for builds. >=20 > I ended up with the following nxb* directories in > /usr/obj/. . . for my context: >=20 > /usr/obj/powerpc.powerpc/nxb > /usr/obj/arm.armv6/nxb > /usr/obj/arm64.aarch64/nxb > /usr/obj/DESTDIRs/clang-armv7-installworld-dist-from-src/nxb-bin > /usr/obj/DESTDIRs/clang-cortexA53-installworld-dist-from-src/nxb-bin > /usr/obj/DESTDIRs/gcc421-powerpc-installworld-dist-from-src/nxb-bin > /usr/obj/DESTDIRs/clang-powerpc-installworld-dist-from-src/nxb-bin > = /usr/obj/DESTDIRs/clang-powerpc64-altbinutils-installworld-dist-from-src/n= xb-bin > /usr/obj/DESTDIRs/clang-cortexA57-installworld-dist-from-src/nxb-bin > /usr/obj/powerpc.powerpc64/nxb I should also have compared and contrasted with my buildworld/buildkernel directory trees: # ls -dlT /usr/obj/*/*.* drwxr-xr-x 3 root wheel 3 Aug 13 15:16:17 2017 = /usr/obj/amd64_clang/amd64.amd64 drwxr-xr-x 3 root wheel 3 Aug 29 01:22:29 2017 = /usr/obj/armv7_clang/arm.armv6 drwxr-xr-x 3 root wheel 3 Aug 29 02:12:29 2017 = /usr/obj/cortexA53_clang/arm64.aarch64 drwxr-xr-x 3 root wheel 3 Aug 29 02:45:54 2017 = /usr/obj/cortexA57_clang/arm64.aarch64 drwxr-xr-x 3 root wheel 3 Aug 28 16:34:43 2017 = /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64 drwxr-xr-x 3 root wheel 3 Aug 29 01:48:58 2017 = /usr/obj/powerpcvtsc_clang/powerpc.powerpc drwxr-xr-x 3 root wheel 3 Aug 29 02:38:08 2017 = /usr/obj/powerpcvtsc_clang_gcc421/powerpc.powerpc (For that last clang built a gcc421 bootstrap compiler.) These were built with the likes of: # more = ~/sys_build_scripts.amd64-host/make_armv7_nodebug_clang_bootstrap-amd64-ho= st.sh=20 kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_armv7_nodebug_clang_bootstrap-amd64-host= -$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.armv7-clang-bootstrap.amd64-hos= t" \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/armv7_clang" \ make $* So the "nxb" directories were outside my build trees. The DESTDIRs listed that had "nxb-bin" directories were just for the poudriere use in the first place. For other uses I'd have created separate install trees with their own names. > However, for example, I did the powerpc ones in > the order (as an experiment that I did not expect > to "work"): >=20 > /usr/obj/DESTDIRs/clang-powerpc-installworld-dist-from-src/nxb-bin > /usr/obj/DESTDIRs/gcc421-powerpc-installworld-dist-from-src/nxb-bin >=20 > and the second reused the material from the first -x . In other > words: the native compiler ended up being based on clang for the > later gcc421 based jail attempt. >=20 > A similar point goes for the pair (in order): >=20 > /usr/obj/DESTDIRs/clang-cortexA53-installworld-dist-from-src/nxb-bin > /usr/obj/DESTDIRs/clang-cortexA57-installworld-dist-from-src/nxb-bin >=20 > in that the A57 one bound to the prior A53 -x content. >=20 > I'm not claiming a problem, just something to know to > expect to avoid. (My 32-bit powerpc activity has lead > to building things based on both compilers because of > the kernel build only working for gcc421-based builds. > Such odd combinations are likely rare.) >=20 >>>=20 >>> null) >>> JAILFS=3Dnone >>> FCT=3Dbuild_native_xtools >>> ;; >>>=20 >>> in order to avoid this. >>>=20 >>> A similar "jail -c" for "-j zrFBSDx64SLarmv7 -a arm.armv6" (and >>> -M /usr/obj/DESTDIRs/clang-armv7-installworld-dist-from-src=20 >>> in my context) and the later bulk build for it seems to be >>> working fine for building lang/gcc7 (as a test). So far: > . . . =3D=3D=3D Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Tue Aug 29 22:53:34 2017 Return-Path: Delivered-To: freebsd-toolchain@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 AF05CDE7BBC; Tue, 29 Aug 2017 22:53:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8EC02744D4; Tue, 29 Aug 2017 22:53:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 5735510AB01; Tue, 29 Aug 2017 18:53:27 -0400 (EDT) From: John Baldwin To: freebsd-arm@freebsd.org Cc: Mark Millard , FreeBSD Toolchain Subject: Re: stable/11 -r322591 using WITH_LLD_IS_LD= : delete-old removes . . ./usr/bin/ld Date: Tue, 29 Aug 2017 15:53:20 -0700 Message-ID: <1771565.Wag2HgbXxa@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <660AE7B2-AB5D-4D8A-9359-3D08BE6DAB7E@dsl-only.net> References: <660AE7B2-AB5D-4D8A-9359-3D08BE6DAB7E@dsl-only.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Tue, 29 Aug 2017 18:53:27 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 22:53:34 -0000 On Tuesday, August 29, 2017 12:52:16 PM Mark Millard wrote: > In some build experiments for amd64 -> aarch64 cross > builds/local-file-system-installs for stable/11 > -r322591 with WITH_LLD_IS_LD= I got examples of > delete-old delete-old-libs deleting the path to ld > after a from-scratch build: This was fixed in HEAD in r309775 which hasn't been MFC'd. There were some followup fixes in r312897 as well. I'll merge those two to 11 in a sec. -- John Baldwin From owner-freebsd-toolchain@freebsd.org Wed Aug 30 10:09:44 2017 Return-Path: Delivered-To: freebsd-toolchain@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 D4483DF4A04 for ; Wed, 30 Aug 2017 10:09:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-93.reflexion.net [208.70.210.93]) (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 8581765F49 for ; Wed, 30 Aug 2017 10:09:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13301 invoked from network); 30 Aug 2017 10:09:42 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 30 Aug 2017 10:09:42 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Wed, 30 Aug 2017 06:09:42 -0400 (EDT) Received: (qmail 32279 invoked from network); 30 Aug 2017 10:09:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Aug 2017 10:09:41 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 19411EC8143; Wed, 30 Aug 2017 03:09:41 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: FYI: qemu-ppc64-static and qemu-ppc-static "live-hang" when I attempt use with poudriere; qemu-arm-static and qemu-aarch64-static work Message-Id: <7BCCF7B6-7AA0-470E-A3ED-9D116E13DBFC@dsl-only.net> Date: Wed, 30 Aug 2017 03:09:40 -0700 Cc: freebsd-arm To: FreeBSD Toolchain , FreeBSD PowerPC ML , FreeBSD Ports X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 10:09:45 -0000 qemu-ppc64-static and qemu-ppc-static "live-hang" when I attempt use them with poudriere, hanging at the command (showing an example process id): /usr/local/bin/qemu-ppc-static /bin/ps -ww -p 47841 -o jid=3D which eats CPU time and grows memory SIZE over time. Examples from after waiting a while in each case: PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND 48319 root 2 103 0 8413M 234M 0K CPU11 11 2:50 = 101.97% /usr/local/bin/qemu-ppc64-static /bin/ps -ww -p 48318 -o jid PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND 47842 root 2 103 0 16597M 455M 0K CPU1 1 5:25 = 96.38% /usr/local/bin/qemu-ppc-static /bin/ps -ww -p 47841 -o jid=3D By contrast I've no such problem with qemu-arm-static or qemu-aarch64-static : these were able to build lang/gcc7 (full bootstrap) in between 4 and 5 hours hours each, the prerequisites also being built in the process. # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 448068 Last Changed Rev: 448068 My attempts to manually use qemu-ppc64-static and qemu-ppc-static (with -L supplied) also get such results. The same for qemu-ppc*-static running a statically linked rescue program (so no -L needed). It appears that qemu-ppc64-static and qemu-ppc-static from emulators/qemu-user-static are broken. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Wed Aug 30 11:00:50 2017 Return-Path: Delivered-To: freebsd-toolchain@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 27AA9DF5ADF; Wed, 30 Aug 2017 11:00:50 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "StartCom Class 2 IV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D00367842; Wed, 30 Aug 2017 11:00:49 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id 2F2AD67F; Wed, 30 Aug 2017 06:00:48 -0500 (CDT) Date: Wed, 30 Aug 2017 06:00:47 -0500 From: Mark Linimon To: Mark Millard Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , FreeBSD Ports , freebsd-arm Subject: Re: FYI: qemu-ppc64-static and qemu-ppc-static "live-hang" when I attempt use with poudriere; qemu-arm-static and qemu-aarch64-static work Message-ID: <20170830110046.GA32595@lonesome.com> References: <7BCCF7B6-7AA0-470E-A3ED-9D116E13DBFC@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7BCCF7B6-7AA0-470E-A3ED-9D116E13DBFC@dsl-only.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 11:00:50 -0000 On Wed, Aug 30, 2017 at 03:09:40AM -0700, Mark Millard wrote: > It appears that qemu-ppc64-static and qemu-ppc-static from > emulators/qemu-user-static are broken. Correct, and known for some time. (fwiw sparc64 hangs as well.) mcl From owner-freebsd-toolchain@freebsd.org Wed Aug 30 23:22:49 2017 Return-Path: Delivered-To: freebsd-toolchain@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 90F2DE0C895 for ; Wed, 30 Aug 2017 23:22:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-94.reflexion.net [208.70.210.94]) (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 5439C84612 for ; Wed, 30 Aug 2017 23:22:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1073 invoked from network); 30 Aug 2017 23:27:55 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 30 Aug 2017 23:27:55 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Wed, 30 Aug 2017 19:22:41 -0400 (EDT) Received: (qmail 23177 invoked from network); 30 Aug 2017 23:22:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Aug 2017 23:22:41 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 846A0EC938A; Wed, 30 Aug 2017 16:22:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: qemu-ppc64-static and qemu-ppc-static "live-hang" when I attempt use with poudriere; qemu-arm-static and qemu-aarch64-static work From: Mark Millard In-Reply-To: <20170830110046.GA32595@lonesome.com> Date: Wed, 30 Aug 2017 16:22:39 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , FreeBSD Ports Content-Transfer-Encoding: quoted-printable Message-Id: References: <7BCCF7B6-7AA0-470E-A3ED-9D116E13DBFC@dsl-only.net> <20170830110046.GA32595@lonesome.com> To: Mark Linimon X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 23:22:49 -0000 On 2017-Aug-30, at 4:00 AM, Mark Linimon wrote: > On Wed, Aug 30, 2017 at 03:09:40AM -0700, Mark Millard wrote: >> It appears that qemu-ppc64-static and qemu-ppc-static from >> emulators/qemu-user-static are broken. >=20 > Correct, and known for some time. (fwiw sparc64 hangs as well.) Looks like qemu-ppc64-static is stuck in a loop, calling repeatedly: do_freebsd_syscall (cpu_env=3D0x860ea3ac0, num=3D58, arg1=3D14, = arg2=3D35995509911, arg3=3D1024, arg4=3D268435904, arg5=3D281494784, = arg6=3D35985701568, arg7=3D515, arg8=3D35985668288) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/syscall.c:210 210 = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/syscall.c: No such file or directory. Which is for: 58 AUE_READLINK STD { ssize_t readlink(char *path, char = *buf, \ size_t count); } As confirmed by (note the "callq 0x60207360 " ): (gdb)=20 lock_user_string (guest_addr=3D14) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/qemu.h:508 508 = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/qemu.h: No such file or directory. (gdb) x/64i 0x0000000060045d3e =3D> 0x60045d3e : callq 0x6004fd20 = 0x60045d43 : test %rax,%rax 0x60045d46 : js 0x6004b99c = 0x60045d4c : inc %rax 0x60045d4f : mov $0x1,%edx 0x60045d54 : mov %rbx,%rdi 0x60045d57 : mov %rax,%rsi 0x60045d5a : callq 0x6003c430 = 0x60045d5f : test %eax,%eax 0x60045d61 : jne 0x6004bce4 = 0x60045d67 : add = 0x26d91b2(%rip),%rbx # 0x6271ef20 0x60045d6e : je 0x6004bce4 = 0x60045d74 : mov $0x3,%edx 0x60045d79 : mov -0x2a8(%rbp),%r14 0x60045d80 : mov %r14,%rdi 0x60045d83 : mov %r12,%rsi 0x60045d86 : callq 0x6003c430 = 0x60045d8b : test %eax,%eax 0x60045d8d : jne 0x6004bce4 = 0x60045d93 : add = 0x26d9186(%rip),%r14 # 0x6271ef20 0x60045d9a : mov = -0x294(%rbp),%r10d 0x60045da1 : mov = $0xfffffffffffffff2,%r13 0x60045da8 : je 0x6004bcf2 = 0x60045dae : mov $0x602b93da,%esi 0x60045db3 : mov %rbx,%rdi 0x60045db6 : callq 0x60230af0 = 0x60045dbb : test %eax,%eax 0x60045dbd : je 0x6004c566 = 0x60045dc3 : mov %rbx,%rdi 0x60045dc6 : callq 0x60158660 0x60045dcb : mov %rax,%rdi 0x60045dce : mov %r14,%rsi 0x60045dd1 : mov %r12,%rdx 0x60045dd4 : callq 0x60207360 = But note that the "lock_user_string (guest_addr=3D14)" and "do_freebsd_syscall (cpu_env=3D0x860ea3ac0, num=3D58, arg1=3D14," indicate that the "readlink(char *path," is using a really small address for the path string. I've not figured a way for poudriere bulk builds to leave behind the source code automatically. So far I've not looked at the qemu-bsd-user source code. I do build with both debug and optimization turned on via bsd.port.mk having: STRIP_CMD=3D ${TRUE} .endif DEBUG_FLAGS?=3D -g +.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG) +CFLAGS:=3D ${CFLAGS} ${DEBUG_FLAGS} +.else CFLAGS:=3D ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} +.endif .if defined(INSTALL_TARGET) INSTALL_TARGET:=3D ${INSTALL_TARGET:S/^install-strip$/install/g} .endif mixed with make.conf indicating to use the new alternative: WANT_QT_VERBOSE_CONFIGURE=3D1 # DEFAULT_VERSIONS+=3Dperl5=3D5.24 gcc=3D7 # # =46rom a local /usr/ports/Mk/bsd.port.mk extension: ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=3D # .if ${.CURDIR:M*/devel/llvm*} #WITH_DEBUG=3D .elif ${.CURDIR:M*/www/webkit-qt5*} #WITH_DEBUG=3D .else WITH_DEBUG=3D .endif MALLOC_PRODUCTION=3D I got as much information as I report above via use of: /usr/local/bin/gdb /usr/local/bin/qemu-user-static and then: run = /usr/obj/DESTDIRs/clang-powerpc64-installworld-dist-from-src/rescue/id and then interrupting it and exploring. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Wed Aug 30 23:32:41 2017 Return-Path: Delivered-To: freebsd-toolchain@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 0C3FDE0CAB4; Wed, 30 Aug 2017 23:32:41 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D150184A01; Wed, 30 Aug 2017 23:32:40 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id v7UNWSVY073465; Wed, 30 Aug 2017 16:32:32 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201708302332.v7UNWSVY073465@gw.catspoiler.org> Date: Wed, 30 Aug 2017 16:32:28 -0700 (PDT) From: Don Lewis Subject: Re: FYI: qemu-ppc64-static and qemu-ppc-static "live-hang" when I attempt use with poudriere; qemu-arm-static and qemu-aarch64-static work To: markmi@dsl-only.net cc: linimon@lonesome.com, freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org, freebsd-ppc@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 23:32:41 -0000 On 30 Aug, Mark Millard wrote: > On 2017-Aug-30, at 4:00 AM, Mark Linimon wrote: > >> On Wed, Aug 30, 2017 at 03:09:40AM -0700, Mark Millard wrote: >>> It appears that qemu-ppc64-static and qemu-ppc-static from >>> emulators/qemu-user-static are broken. >> >> Correct, and known for some time. (fwiw sparc64 hangs as well.) > > Looks like qemu-ppc64-static is stuck in a loop, calling > repeatedly: > > do_freebsd_syscall (cpu_env=0x860ea3ac0, num=58, arg1=14, arg2=35995509911, arg3=1024, arg4=268435904, arg5=281494784, arg6=35985701568, arg7=515, arg8=35985668288) > at /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/syscall.c:210 > 210 /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/syscall.c: No such file or directory. > > Which is for: > > 58 AUE_READLINK STD { ssize_t readlink(char *path, char *buf, \ > size_t count); } > > As confirmed by (note the "callq 0x60207360 " ): > > (gdb) > lock_user_string (guest_addr=14) at /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/qemu.h:508 > 508 /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/qemu.h: No such file or directory. > > (gdb) x/64i 0x0000000060045d3e > => 0x60045d3e : callq 0x6004fd20 > 0x60045d43 : test %rax,%rax > 0x60045d46 : js 0x6004b99c > 0x60045d4c : inc %rax > 0x60045d4f : mov $0x1,%edx > 0x60045d54 : mov %rbx,%rdi > 0x60045d57 : mov %rax,%rsi > 0x60045d5a : callq 0x6003c430 > 0x60045d5f : test %eax,%eax > 0x60045d61 : jne 0x6004bce4 > 0x60045d67 : add 0x26d91b2(%rip),%rbx # 0x6271ef20 > 0x60045d6e : je 0x6004bce4 > 0x60045d74 : mov $0x3,%edx > 0x60045d79 : mov -0x2a8(%rbp),%r14 > 0x60045d80 : mov %r14,%rdi > 0x60045d83 : mov %r12,%rsi > 0x60045d86 : callq 0x6003c430 > 0x60045d8b : test %eax,%eax > 0x60045d8d : jne 0x6004bce4 > 0x60045d93 : add 0x26d9186(%rip),%r14 # 0x6271ef20 > 0x60045d9a : mov -0x294(%rbp),%r10d > 0x60045da1 : mov $0xfffffffffffffff2,%r13 > 0x60045da8 : je 0x6004bcf2 > 0x60045dae : mov $0x602b93da,%esi > 0x60045db3 : mov %rbx,%rdi > 0x60045db6 : callq 0x60230af0 > 0x60045dbb : test %eax,%eax > 0x60045dbd : je 0x6004c566 > 0x60045dc3 : mov %rbx,%rdi > 0x60045dc6 : callq 0x60158660 > 0x60045dcb : mov %rax,%rdi > 0x60045dce : mov %r14,%rsi > 0x60045dd1 : mov %r12,%rdx > 0x60045dd4 : callq 0x60207360 > > But note that the "lock_user_string (guest_addr=14)" and > "do_freebsd_syscall (cpu_env=0x860ea3ac0, num=58, arg1=14," > indicate that the "readlink(char *path," is using a really > small address for the path string. > > > I've not figured a way for poudriere bulk builds to leave > behind the source code automatically. So far I've not > looked at the qemu-bsd-user source code. I do build with > both debug and optimization turned on via bsd.port.mk > having: The -w option will create a tarball of the work directory if the package build fails. I also often use the testport -i option I want to poke around in the WRKDIR after a build. From owner-freebsd-toolchain@freebsd.org Thu Aug 31 03:43:55 2017 Return-Path: Delivered-To: freebsd-toolchain@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 BCAD0E146F3 for ; Thu, 31 Aug 2017 03:43:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-94.reflexion.net [208.70.210.94]) (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 7F4386747F for ; Thu, 31 Aug 2017 03:43:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 810 invoked from network); 31 Aug 2017 03:43:53 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 31 Aug 2017 03:43:53 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Wed, 30 Aug 2017 23:43:53 -0400 (EDT) Received: (qmail 11559 invoked from network); 31 Aug 2017 03:43:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 31 Aug 2017 03:43:53 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 5F07EEC86F0; Wed, 30 Aug 2017 20:43:52 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: qemu-ppc64-static and qemu-ppc-static "live-hang" when I attempt use with poudriere; qemu-arm-static and qemu-aarch64-static work From: Mark Millard In-Reply-To: <201708302332.v7UNWSVY073465@gw.catspoiler.org> Date: Wed, 30 Aug 2017 20:43:51 -0700 Cc: linimon@lonesome.com, freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org, freebsd-ppc@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9B916738-394B-48B7-AA2E-6193F54760B3@dsl-only.net> References: <201708302332.v7UNWSVY073465@gw.catspoiler.org> To: Don Lewis X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 03:43:55 -0000 On 2017-Aug-30, at 4:32 PM, Don Lewis wrote: > On 30 Aug, Mark Millard wrote: >> On 2017-Aug-30, at 4:00 AM, Mark Linimon = wrote: >>=20 >>> On Wed, Aug 30, 2017 at 03:09:40AM -0700, Mark Millard wrote: >>>> It appears that qemu-ppc64-static and qemu-ppc-static from >>>> emulators/qemu-user-static are broken. >>>=20 >>> Correct, and known for some time. (fwiw sparc64 hangs as well.) >>=20 >> Looks like qemu-ppc64-static is stuck in a loop, calling >> repeatedly: >>=20 >> do_freebsd_syscall (cpu_env=3D0x860ea3ac0, num=3D58, arg1=3D14, = arg2=3D35995509911, arg3=3D1024, arg4=3D268435904, arg5=3D281494784, = arg6=3D35985701568, arg7=3D515, arg8=3D35985668288) >> at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/syscall.c:210 >> 210 = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/syscall.c: No such file or directory. >>=20 >> Which is for: >>=20 >> 58 AUE_READLINK STD { ssize_t readlink(char *path, char = *buf, \ >> size_t count); } >>=20 >> As confirmed by (note the "callq 0x60207360 " ): >>=20 >> (gdb)=20 >> lock_user_string (guest_addr=3D14) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/qemu.h:508 >> 508 = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/qemu.h: No such file or directory. >>=20 >> (gdb) x/64i 0x0000000060045d3e >> =3D> 0x60045d3e : callq 0x6004fd20 = >> 0x60045d43 : test %rax,%rax >> 0x60045d46 : js 0x6004b99c = >> 0x60045d4c : inc %rax >> 0x60045d4f : mov $0x1,%edx >> 0x60045d54 : mov %rbx,%rdi >> 0x60045d57 : mov %rax,%rsi >> 0x60045d5a : callq 0x6003c430 = >> 0x60045d5f : test %eax,%eax >> 0x60045d61 : jne 0x6004bce4 = >> 0x60045d67 : add = 0x26d91b2(%rip),%rbx # 0x6271ef20 >> 0x60045d6e : je 0x6004bce4 = >> 0x60045d74 : mov $0x3,%edx >> 0x60045d79 : mov -0x2a8(%rbp),%r14 >> 0x60045d80 : mov %r14,%rdi >> 0x60045d83 : mov %r12,%rsi >> 0x60045d86 : callq 0x6003c430 = >> 0x60045d8b : test %eax,%eax >> 0x60045d8d : jne 0x6004bce4 = >> 0x60045d93 : add = 0x26d9186(%rip),%r14 # 0x6271ef20 >> 0x60045d9a : mov = -0x294(%rbp),%r10d >> 0x60045da1 : mov = $0xfffffffffffffff2,%r13 >> 0x60045da8 : je 0x6004bcf2 = >> 0x60045dae : mov $0x602b93da,%esi >> 0x60045db3 : mov %rbx,%rdi >> 0x60045db6 : callq 0x60230af0 = >> 0x60045dbb : test %eax,%eax >> 0x60045dbd : je 0x6004c566 = >> 0x60045dc3 : mov %rbx,%rdi >> 0x60045dc6 : callq 0x60158660 >> 0x60045dcb : mov %rax,%rdi >> 0x60045dce : mov %r14,%rsi >> 0x60045dd1 : mov %r12,%rdx >> 0x60045dd4 : callq 0x60207360 = >>=20 >> But note that the "lock_user_string (guest_addr=3D14)" and >> "do_freebsd_syscall (cpu_env=3D0x860ea3ac0, num=3D58, arg1=3D14," >> indicate that the "readlink(char *path," is using a really >> small address for the path string. >>=20 >>=20 >> I've not figured a way for poudriere bulk builds to leave >> behind the source code automatically. So far I've not >> looked at the qemu-bsd-user source code. I do build with >> both debug and optimization turned on via bsd.port.mk >> having: >=20 > The -w option will create a tarball of the work directory if the > package build fails. I also often use the testport -i option I want = to > poke around in the WRKDIR after a build. I've been using -w right along. But I'd not used testport at all. It looks to me like the syscall errno handling is messed up. The details that I've observed follow. It follows a simplified sequence of discovery as far a presentation order goes. The looping code is: static inline void target_cpu_loop(CPUPPCState *env) { CPUState *cs =3D CPU(ppc_env_get_cpu(env)); target_siginfo_t info; int trapnr; target_ulong ret; =20 for(;;) { cpu_exec_start(cs); trapnr =3D cpu_exec(cs); cpu_exec_end(cs); process_queued_cpu_work(cs); =20 switch(trapnr) { . . . case POWERPC_EXCP_SYSCALL_USER: /* system call in user-mode emulation */ /* WARNING: * PPC ABI uses overflow flag in cr0 to signal an error * in syscalls. */ env->crf[0] &=3D ~0x1; ret =3D do_freebsd_syscall(env, env->gpr[0], env->gpr[3], = env->gpr[4], env->gpr[5], env->gpr[6], env->gpr[7], env->gpr[8], env->gpr[9], env->gpr[10]); if (ret =3D=3D (target_ulong)(-TARGET_QEMU_ESIGRETURN)) { /* Returning from a successful sigreturn syscall. Avoid corrupting register state. */ break; } if (ret > (target_ulong)(-515)) { env->crf[0] |=3D 0x1; ret =3D -ret; } env->gpr[3] =3D ret; break; . . . } process_pending_signals(env); } } The observed env->gpr[3] =3D=3D 14 is from a prior loop iteration having ret =3D=3D 14 in the: env->gpr[3] =3D ret; Prior to this were the values (as seen via lock_user_string): guest_addr=3D278408977 guest_addr=3D2 That 2 also came from the prior ret =3D=3D 2 in the: env->gpr[3] =3D ret; from when the 278408977 was in being attempted. For both the ret =3D=3D 2 and ret =3D=3D 14 were from: ret =3D -ret; so the return values from do_freebsd_syscall were -2 and -14 (interpreted as signed). The return values trace back to the following code, where TARGET_EFAULT =3D=3D 14 : static inline abi_long do_bsd_readlink(CPUArchState *env, abi_long arg1, abi_long arg2, abi_long arg3) { abi_long ret; void *p1, *p2; =20 LOCK_PATH(p1, arg1); p2 =3D lock_user(VERIFY_WRITE, arg2, arg3, 0); if (p2 =3D=3D NULL) { UNLOCK_PATH(p1, arg1); return -TARGET_EFAULT; } #ifdef __FreeBSD__ if (strcmp(p1, "/proc/curproc/file") =3D=3D 0) { CPUState *cpu =3D ENV_GET_CPU(env); TaskState *ts =3D (TaskState *)cpu->opaque; strncpy(p2, ts->bprm->fullpath, arg3); ret =3D MIN((abi_long)strlen(ts->bprm->fullpath), arg3); } else #endif ret =3D get_errno(readlink(path(p1), p2, arg3)); unlock_user(p2, arg2, ret); UNLOCK_PATH(p1, arg1); return ret; } The 2 is from: ret =3D get_errno(readlink(path(p1), p2, arg3)); At the time the p1 points to "/etc/malloc.conf": (gdb) step=20 path (name=3D0x10982f11 "/etc/malloc.conf") at util/path.c:173 169 const char *path(const char *name) 170 { 171 /* Only do absolute paths: quick and dirty, but should = mostly be OK. 172 Could do relative by tracking cwd. */ (gdb)=20 173 if (!base || !name || name[0] !=3D '/') 174 return name; 175=09 176 return follow_path(base, name) ?: name; 177 } (gdb) print base $8 =3D (struct pathelem *) 0x0 So name is returned unchanged. The 2 is in turn from: #define __ENOENT 2 /* No such file or directory */ Overall one oddity is that this code structure seems to use -ret from: ret =3D do_freebsd_syscall(env, env->gpr[0], env->gpr[3], = env->gpr[4], env->gpr[5], env->gpr[6], env->gpr[7], env->gpr[8], env->gpr[9], env->gpr[10]); to retry the same operation again the next iteration, but with env->gpr[3] =3D=3D -ret (as ret was on the return of do_freebsd_syscall ). Once abs(ret) =3D=3D 14 it is fully stuck repeating itself. I've no clue if: env->gpr[3] =3D ret; even makes sense here. I've not tried to track down the memory leak activity that is associated. Nor have I checked anything for the: cpu_exec_start(cs); trapnr =3D cpu_exec(cs); cpu_exec_end(cs); process_queued_cpu_work(cs); activity. It likely contributes to why the loop retries the readlink again (with a junk address for the path). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Aug 31 19:13:21 2017 Return-Path: Delivered-To: freebsd-toolchain@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 12528E04037 for ; Thu, 31 Aug 2017 19:13:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-94.reflexion.net [208.70.210.94]) (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 BA25F64202 for ; Thu, 31 Aug 2017 19:13:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15751 invoked from network); 31 Aug 2017 19:13:19 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 31 Aug 2017 19:13:19 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Thu, 31 Aug 2017 15:13:19 -0400 (EDT) Received: (qmail 15339 invoked from network); 31 Aug 2017 19:13:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 31 Aug 2017 19:13:18 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 24003EC7A6F; Thu, 31 Aug 2017 12:13:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: qemu-ppc64-static and qemu-ppc-static "live-hang" when I attempt use with poudriere; qemu-arm-static and qemu-aarch64-static work From: Mark Millard In-Reply-To: <9B916738-394B-48B7-AA2E-6193F54760B3@dsl-only.net> Date: Thu, 31 Aug 2017 12:13:17 -0700 Cc: Mark Linimon , FreeBSD Toolchain , FreeBSD Ports , freebsd-ppc@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <85B5ADE0-5573-4E04-8EC3-CB5751C035FF@dsl-only.net> References: <201708302332.v7UNWSVY073465@gw.catspoiler.org> <9B916738-394B-48B7-AA2E-6193F54760B3@dsl-only.net> To: Don Lewis X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 19:13:21 -0000 [Turns out that the emulated program counter is not progressing for syscall emulation, at least for syscall falure cases.] On 2017-Aug-30, at 8:43 PM, Mark Millard wrote: > On 2017-Aug-30, at 4:32 PM, Don Lewis wrote: >=20 >> On 30 Aug, Mark Millard wrote: >>> On 2017-Aug-30, at 4:00 AM, Mark Linimon = wrote: >>>=20 >>>> On Wed, Aug 30, 2017 at 03:09:40AM -0700, Mark Millard wrote: >>>>> It appears that qemu-ppc64-static and qemu-ppc-static from >>>>> emulators/qemu-user-static are broken. >>>>=20 >>>> Correct, and known for some time. (fwiw sparc64 hangs as well.) >>>=20 >>> Looks like qemu-ppc64-static is stuck in a loop, calling >>> repeatedly: >>>=20 >>> do_freebsd_syscall (cpu_env=3D0x860ea3ac0, num=3D58, arg1=3D14, = arg2=3D35995509911, arg3=3D1024, arg4=3D268435904, arg5=3D281494784, = arg6=3D35985701568, arg7=3D515, arg8=3D35985668288) >>> at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/syscall.c:210 >>> 210 = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/syscall.c: No such file or directory. >>>=20 >>> Which is for: >>>=20 >>> 58 AUE_READLINK STD { ssize_t readlink(char *path, char = *buf, \ >>> size_t count); } >>>=20 >>> As confirmed by (note the "callq 0x60207360 " ): >>>=20 >>> (gdb)=20 >>> lock_user_string (guest_addr=3D14) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/qemu.h:508 >>> 508 = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/qemu.h: No such file or directory. >>>=20 >>> (gdb) x/64i 0x0000000060045d3e >>> =3D> 0x60045d3e : callq 0x6004fd20 = >>> 0x60045d43 : test %rax,%rax >>> 0x60045d46 : js 0x6004b99c = >>> 0x60045d4c : inc %rax >>> 0x60045d4f : mov $0x1,%edx >>> 0x60045d54 : mov %rbx,%rdi >>> 0x60045d57 : mov %rax,%rsi >>> 0x60045d5a : callq 0x6003c430 = >>> 0x60045d5f : test %eax,%eax >>> 0x60045d61 : jne 0x6004bce4 = >>> 0x60045d67 : add = 0x26d91b2(%rip),%rbx # 0x6271ef20 >>> 0x60045d6e : je 0x6004bce4 = >>> 0x60045d74 : mov $0x3,%edx >>> 0x60045d79 : mov -0x2a8(%rbp),%r14 >>> 0x60045d80 : mov %r14,%rdi >>> 0x60045d83 : mov %r12,%rsi >>> 0x60045d86 : callq 0x6003c430 = >>> 0x60045d8b : test %eax,%eax >>> 0x60045d8d : jne 0x6004bce4 = >>> 0x60045d93 : add = 0x26d9186(%rip),%r14 # 0x6271ef20 >>> 0x60045d9a : mov = -0x294(%rbp),%r10d >>> 0x60045da1 : mov = $0xfffffffffffffff2,%r13 >>> 0x60045da8 : je 0x6004bcf2 = >>> 0x60045dae : mov $0x602b93da,%esi >>> 0x60045db3 : mov %rbx,%rdi >>> 0x60045db6 : callq 0x60230af0 = >>> 0x60045dbb : test %eax,%eax >>> 0x60045dbd : je 0x6004c566 = >>> 0x60045dc3 : mov %rbx,%rdi >>> 0x60045dc6 : callq 0x60158660 >>> 0x60045dcb : mov %rax,%rdi >>> 0x60045dce : mov %r14,%rsi >>> 0x60045dd1 : mov %r12,%rdx >>> 0x60045dd4 : callq 0x60207360 = >>>=20 >>> But note that the "lock_user_string (guest_addr=3D14)" and >>> "do_freebsd_syscall (cpu_env=3D0x860ea3ac0, num=3D58, arg1=3D14," >>> indicate that the "readlink(char *path," is using a really >>> small address for the path string. >>>=20 >>>=20 >>> I've not figured a way for poudriere bulk builds to leave >>> behind the source code automatically. So far I've not >>> looked at the qemu-bsd-user source code. I do build with >>> both debug and optimization turned on via bsd.port.mk >>> having: >>=20 >> The -w option will create a tarball of the work directory if the >> package build fails. I also often use the testport -i option I want = to >> poke around in the WRKDIR after a build. >=20 > I've been using -w right along. But I'd not used testport at all. >=20 > It looks to me like the syscall errno handling is messed > up. The details that I've observed follow. It follows > a simplified sequence of discovery as far a presentation > order goes. >=20 > The looping code is: >=20 > static inline void target_cpu_loop(CPUPPCState *env) > { > CPUState *cs =3D CPU(ppc_env_get_cpu(env)); > target_siginfo_t info; > int trapnr; > target_ulong ret; >=20 > for(;;) { > cpu_exec_start(cs); > trapnr =3D cpu_exec(cs); > cpu_exec_end(cs); > process_queued_cpu_work(cs); >=20 > switch(trapnr) { > . . . > case POWERPC_EXCP_SYSCALL_USER: > /* system call in user-mode emulation */ > /* WARNING: > * PPC ABI uses overflow flag in cr0 to signal an error > * in syscalls. > */ > env->crf[0] &=3D ~0x1; > ret =3D do_freebsd_syscall(env, env->gpr[0], env->gpr[3], = env->gpr[4], > env->gpr[5], env->gpr[6], env->gpr[7], > env->gpr[8], env->gpr[9], env->gpr[10]); > if (ret =3D=3D (target_ulong)(-TARGET_QEMU_ESIGRETURN)) { > /* Returning from a successful sigreturn syscall. > Avoid corrupting register state. */ > break; > } > if (ret > (target_ulong)(-515)) { > env->crf[0] |=3D 0x1; > ret =3D -ret; > } > env->gpr[3] =3D ret; > break; > . . . > } > process_pending_signals(env); > } > } >=20 > The observed env->gpr[3] =3D=3D 14 is from a prior loop > iteration having ret =3D=3D 14 in the: >=20 > env->gpr[3] =3D ret; >=20 > Prior to this were the values (as seen via > lock_user_string): >=20 > guest_addr=3D278408977 > guest_addr=3D2 >=20 > That 2 also came from the prior ret =3D=3D 2 in the: >=20 > env->gpr[3] =3D ret; >=20 > from when the 278408977 was in being attempted. >=20 > For both the ret =3D=3D 2 and ret =3D=3D 14 were from: >=20 > ret =3D -ret; >=20 > so the return values from do_freebsd_syscall were > -2 and -14 (interpreted as signed). >=20 > The return values trace back to the following code, > where TARGET_EFAULT =3D=3D 14 : >=20 > static inline abi_long do_bsd_readlink(CPUArchState *env, abi_long = arg1, > abi_long arg2, abi_long arg3) > { > abi_long ret; > void *p1, *p2; >=20 > LOCK_PATH(p1, arg1); > p2 =3D lock_user(VERIFY_WRITE, arg2, arg3, 0); > if (p2 =3D=3D NULL) { > UNLOCK_PATH(p1, arg1); > return -TARGET_EFAULT; > } > #ifdef __FreeBSD__ > if (strcmp(p1, "/proc/curproc/file") =3D=3D 0) { > CPUState *cpu =3D ENV_GET_CPU(env); > TaskState *ts =3D (TaskState *)cpu->opaque; > strncpy(p2, ts->bprm->fullpath, arg3); > ret =3D MIN((abi_long)strlen(ts->bprm->fullpath), arg3); > } else > #endif > ret =3D get_errno(readlink(path(p1), p2, arg3)); > unlock_user(p2, arg2, ret); > UNLOCK_PATH(p1, arg1); >=20 > return ret; > } >=20 > The 2 is from: >=20 > ret =3D get_errno(readlink(path(p1), p2, arg3)); >=20 > At the time the p1 points to "/etc/malloc.conf": >=20 > (gdb) step=20 > path (name=3D0x10982f11 "/etc/malloc.conf") at util/path.c:173 >=20 > 169 const char *path(const char *name) > 170 { > 171 /* Only do absolute paths: quick and dirty, but should = mostly be OK. > 172 Could do relative by tracking cwd. */ > (gdb)=20 > 173 if (!base || !name || name[0] !=3D '/') > 174 return name; > 175=09 > 176 return follow_path(base, name) ?: name; > 177 } >=20 > (gdb) print base > $8 =3D (struct pathelem *) 0x0 >=20 > So name is returned unchanged. >=20 >=20 > The 2 is in turn from: >=20 > #define __ENOENT 2 /* No such file or = directory */ >=20 >=20 > Overall one oddity is that this code structure > seems to use -ret from: >=20 > ret =3D do_freebsd_syscall(env, env->gpr[0], env->gpr[3], = env->gpr[4], > env->gpr[5], env->gpr[6], env->gpr[7], > env->gpr[8], env->gpr[9], env->gpr[10]); >=20 > to retry the same operation again the next iteration, > but with env->gpr[3] =3D=3D -ret (as ret was on the return > of do_freebsd_syscall ). >=20 > Once abs(ret) =3D=3D 14 it is fully stuck repeating itself. >=20 > I've no clue if: >=20 > env->gpr[3] =3D ret; >=20 > even makes sense here. >=20 > I've not tried to track down the memory leak activity > that is associated. >=20 > Nor have I checked anything for the: >=20 > cpu_exec_start(cs); > trapnr =3D cpu_exec(cs); > cpu_exec_end(cs); > process_queued_cpu_work(cs); >=20 > activity. It likely contributes to why the loop > retries the readlink again (with a junk address > for the path). I do not see activity advancing the emulated program counter as this looping/retrying happens. Nor anything that is adjusting the problematical re-used env->gpr[3] other than the: 516 env->gpr[3] =3D ret; after the negation of ret for the syscall failure handling. This is confirmed by the following: (gdb) bt #0 cpu_tb_exec (cpu=3D0x860e9b8c0, itb=3D0x60723340 = ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:141 #1 0x0000000060039cb5 in cpu_loop_exec_tb (cpu=3D, = tb=3D, last_tb=3D, tb_exit=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:574 #2 cpu_exec (cpu=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:672 #3 0x000000006003c988 in target_cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/ppc/target_arch_cpu.h:139 #4 cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:121 #5 0x000000006003e003 in main (argc=3D, argv=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:516 . . . (gdb) list 569 { 570 uintptr_t ret; 571 int32_t insns_left; 572=09 573 trace_exec_tb(tb, tb->pc); 574 ret =3D cpu_tb_exec(cpu, tb); 575 tb =3D (TranslationBlock *)(ret & ~TB_EXIT_MASK); 576 *tb_exit =3D ret & TB_EXIT_MASK; 577 if (*tb_exit !=3D TB_EXIT_REQUESTED) { 578 *last_tb =3D tb; . . . cpu_tb_exec (cpu=3D0x860e9b8c0, itb=3D0x60723340 = ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:141 141 CPUArchState *env =3D cpu->env_ptr; (gdb) print/x itb->pc $16 =3D 0x1074d784 (gdb) c Continuing. Thread 1 hit Breakpoint 9, cpu_tb_exec (cpu=3D0x860e9b8c0, = itb=3D0x60723340 ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:141 141 CPUArchState *env =3D cpu->env_ptr; . . . (gdb) print/x itb->pc $18 =3D 0x1074d784 (gdb) c Continuing. Thread 1 hit Breakpoint 9, cpu_tb_exec (cpu=3D0x860e9b8c0, = itb=3D0x60723340 ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:141 141 CPUArchState *env =3D cpu->env_ptr; (gdb) print/x itb->pc $19 =3D 0x1074d784 (gdb) c Continuing. Thread 1 hit Breakpoint 9, cpu_tb_exec (cpu=3D0x860e9b8c0, = itb=3D0x60723340 ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:141 141 CPUArchState *env =3D cpu->env_ptr; (gdb) print/x itb->pc $20 =3D 0x1074d784 and so on. So it appears that syscall emulation does not progress the emulated instruction pointer and so the syscall repeats over and over. (I've still not tracked down what is leaking memory during this looping. But that is probably a secodnary concern at this point.) So how does the code get from: 139 trapnr =3D cpu_exec(cs); to (re-)trying the failed syscall (readlink) attempt? (gdb) bt #0 0x00000000601e25c0 in siglongjmp () #1 0x000000006003a1aa in cpu_loop_exit_restore (cpu=3D, = pc=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec-common.c:77 #2 0x00000000600e0eeb in raise_exception_err_ra (env=3D, = exception=3D, error_code=3D0, raddr=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/excp_helper.c:905 #3 helper_raise_exception_err (env=3D, = exception=3D, error_code=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/excp_helper.c:928 #4 0x00000000607233e6 in static_code_gen_buffer () #5 0x0000000060039ffa in cpu_tb_exec (cpu=3D0x860e9b8c0, itb=3D0x60723340= ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:166 #6 0x0000000060039cb5 in cpu_loop_exec_tb (cpu=3D, = tb=3D, last_tb=3D, tb_exit=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:574 #7 cpu_exec (cpu=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:672 #8 0x000000006003c988 in target_cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/ppc/target_arch_cpu.h:139 #9 cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:121 #10 0x000000006003e003 in main (argc=3D, argv=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:516 It does a siglongjmp via helper_raise_execption_err : (gdb) up #1 0x0000000060039ffa in cpu_tb_exec (cpu=3D0x860e9b8c0, itb=3D0x60723340= ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:166 166 ret =3D tcg_qemu_tb_exec(env, tb_ptr); (gdb) list 161 qemu_log_unlock(); 162 } 163 #endif /* DEBUG_DISAS */ 164=09 165 cpu->can_do_io =3D !use_icount; 166 ret =3D tcg_qemu_tb_exec(env, tb_ptr); 167 cpu->can_do_io =3D 1; 168 last_tb =3D (TranslationBlock *)(ret & ~TB_EXIT_MASK); 169 tb_exit =3D ret & TB_EXIT_MASK; 170 trace_exec_tb_exit(last_tb, tb_exit); (gdb) print tb_ptr $11 =3D (uint8_t *) 0x607233c0 = "A\213n\354\205\355\017\214\037" 0x607233c0 : mov -0x14(%r14),%ebp 0x607233c4 : test %ebp,%ebp 0x607233c6 : jl 0x607233eb = 0x607233cc : movq = $0x1074d784,0x3c8(%r14) 0x607233d7 : mov %r14,%rdi 0x607233da : mov $0x203,%esi 0x607233df : xor %edx,%edx 0x607233e1 : callq 0x600e0ed0 = =3D> 0x607233e6 : jmpq 0x6071ef06 = 0x607233eb : mov $0x60723343,%eax 0x607233f0 : jmpq 0x6071ef08 = The exception is exception=3D=3D515 . 515 is the figure matching up with POWERPC_EXCP_SYSCALL_USER . (gdb) stepi helper_raise_exception_err (env=3D0x860ea3ac0, exception=3D515, = error_code=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/excp_helper.c:927 927 { (gdb) bt #0 helper_raise_exception_err (env=3D0x860ea3ac0, exception=3D515, = error_code=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/excp_helper.c:927 #1 0x00000000607233e6 in static_code_gen_buffer () #2 0x0000000060039ffa in cpu_tb_exec (cpu=3D0x860e9b8c0, itb=3D0x60723340= ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:166 #3 0x0000000060039cb5 in cpu_loop_exec_tb (cpu=3D, = tb=3D, last_tb=3D, tb_exit=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:574 #4 cpu_exec (cpu=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:672 #5 0x000000006003c988 in target_cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/ppc/target_arch_cpu.h:139 #6 cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:121 #7 0x000000006003e003 in main (argc=3D, argv=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:516 Later there is: raise_exception_err_ra (env=3D0x860ea3ac0, exception=3D515, = error_code=3D0, raddr=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/excp_helper.c:903 903 cs->exception_index =3D exception; and then: (gdb) s cpu_loop_exit_restore (cpu=3D0x860e9b8c0, pc=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec-common.c:74 74 if (pc) { (gdb) n 77 siglongjmp(cpu->jmp_env, 1); (gdb) n 0x00000000600398e9 in cpu_exec (cpu=3D0x860e9b8c0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:645 645 if (sigsetjmp(cpu->jmp_env, 0) !=3D 0) { (gdb) bt #0 0x00000000600398e9 in cpu_exec (cpu=3D0x860e9b8c0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:645 #1 0x000000006003c988 in target_cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/ppc/target_arch_cpu.h:139 #2 cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:121 #3 0x000000006003e003 in main (argc=3D, argv=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:516 (gdb) n 651 cpu =3D current_cpu; (gdb)=20 652 cc =3D CPU_GET_CLASS(cpu); (gdb)=20 658 cpu->can_do_io =3D 1; (gdb)=20 659 tb_lock_reset(); (gdb)=20 660 if (qemu_mutex_iothread_locked()) { (gdb)=20 661 qemu_mutex_unlock_iothread(); (gdb)=20 666 while (!cpu_handle_exception(cpu, &ret)) { (gdb)=20 679 cc->cpu_exec_exit(cpu); (gdb) n 680 rcu_read_unlock(); (gdb) n 683 } (gdb) n target_cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/ppc/target_arch_cpu.h:140 140 cpu_exec_end(cs); And it sends up back in: 141 process_queued_cpu_work(cs); 142=09 143 switch(trapnr) { . . . 497 case POWERPC_EXCP_SYSCALL_USER: 498 /* system call in user-mode emulation */ 499 /* WARNING: 500 * PPC ABI uses overflow flag in cr0 to signal an = error 501 * in syscalls. 502 */ (gdb)=20 503 env->crf[0] &=3D ~0x1; 504 ret =3D do_freebsd_syscall(env, env->gpr[0], = env->gpr[3], env->gpr[4], 505 env->gpr[5], env->gpr[6], = env->gpr[7], 506 env->gpr[8], env->gpr[9], = env->gpr[10]); 507 if (ret =3D=3D = (target_ulong)(-TARGET_QEMU_ESIGRETURN)) { 508 /* Returning from a successful sigreturn = syscall. 509 Avoid corrupting register state. */ 510 break; 511 } 512 if (ret > (target_ulong)(-515)) { (gdb)=20 513 env->crf[0] |=3D 0x1; 514 ret =3D -ret; 515 } 516 env->gpr[3] =3D ret; 517 break; =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Aug 31 19:40:58 2017 Return-Path: Delivered-To: freebsd-toolchain@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 8B435E048B8 for ; Thu, 31 Aug 2017 19:40:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-94.reflexion.net [208.70.210.94]) (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 4DEB564CA6 for ; Thu, 31 Aug 2017 19:40:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10413 invoked from network); 31 Aug 2017 19:46:11 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 31 Aug 2017 19:46:11 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Thu, 31 Aug 2017 15:40:56 -0400 (EDT) Received: (qmail 4786 invoked from network); 31 Aug 2017 19:40:56 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 31 Aug 2017 19:40:56 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 79869EC7ED7; Thu, 31 Aug 2017 12:40:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: qemu-ppc64-static and qemu-ppc-static "live-hang" when I attempt use with poudriere; qemu-arm-static and qemu-aarch64-static work From: Mark Millard In-Reply-To: <85B5ADE0-5573-4E04-8EC3-CB5751C035FF@dsl-only.net> Date: Thu, 31 Aug 2017 12:40:54 -0700 Cc: Don Lewis , Mark Linimon , FreeBSD Toolchain , FreeBSD Ports , freebsd-ppc@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <201708302332.v7UNWSVY073465@gw.catspoiler.org> <9B916738-394B-48B7-AA2E-6193F54760B3@dsl-only.net> <85B5ADE0-5573-4E04-8EC3-CB5751C035FF@dsl-only.net> To: Sean Bruno X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 19:40:58 -0000 [Just adding Sean Bruno in case the information is new to him. I top post a note for that.] Sean: The below reports on what I've found for what is happening for qemu-ppc64-static (and possibly others) when it gets stuck eating CPU time (and leaking memory), at least for the example I ran into (that basically blocks all use of qemu-ppc64-static it happens very early in all(?) attempted uses that load. The content reflects my exploration order. The summary is: A) I've found an example context where the emulated pc does not progress and it ends up looping repeating a syscall. B) Given that is involved: I've found that env->gpr[3] handling for failed syscall attempts contributes to the detailed failure behaviors. (This part is, of course, likely very powerpc specific.) But I found (B) before finding (A) as its context and (A) might be the only problem for all I know: having the emulated program counter progress correctly might end up dealing with env->gpr[3] correctly in the newly executed code. At this point I've no clue where the emulated PC should be adjusted in the code or what the detailed adjustment rules should be for the context, only that the PC is not being adjusted now but needs to be adjusted. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Aug-31, at 12:13 PM, Mark Millard = wrote: [Turns out that the emulated program counter is not progressing for syscall emulation, at least for [some] syscall [failure] cases.] On 2017-Aug-30, at 8:43 PM, Mark Millard wrote: > On 2017-Aug-30, at 4:32 PM, Don Lewis wrote: >=20 >> On 30 Aug, Mark Millard wrote: >>> On 2017-Aug-30, at 4:00 AM, Mark Linimon = wrote: >>>=20 >>>> On Wed, Aug 30, 2017 at 03:09:40AM -0700, Mark Millard wrote: >>>>> It appears that qemu-ppc64-static and qemu-ppc-static from >>>>> emulators/qemu-user-static are broken. >>>>=20 >>>> Correct, and known for some time. (fwiw sparc64 hangs as well.) >>>=20 >>> Looks like qemu-ppc64-static is stuck in a loop, calling >>> repeatedly: >>>=20 >>> do_freebsd_syscall (cpu_env=3D0x860ea3ac0, num=3D58, arg1=3D14, = arg2=3D35995509911, arg3=3D1024, arg4=3D268435904, arg5=3D281494784, = arg6=3D35985701568, arg7=3D515, arg8=3D35985668288) >>> at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/syscall.c:210 >>> 210 = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/syscall.c: No such file or directory. >>>=20 >>> Which is for: >>>=20 >>> 58 AUE_READLINK STD { ssize_t readlink(char *path, char = *buf, \ >>> size_t count); } >>>=20 >>> As confirmed by (note the "callq 0x60207360 " ): >>>=20 >>> (gdb)=20 >>> lock_user_string (guest_addr=3D14) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/qemu.h:508 >>> 508 = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/qemu.h: No such file or directory. >>>=20 >>> (gdb) x/64i 0x0000000060045d3e >>> =3D> 0x60045d3e : callq 0x6004fd20 = >>> 0x60045d43 : test %rax,%rax >>> 0x60045d46 : js 0x6004b99c = >>> 0x60045d4c : inc %rax >>> 0x60045d4f : mov $0x1,%edx >>> 0x60045d54 : mov %rbx,%rdi >>> 0x60045d57 : mov %rax,%rsi >>> 0x60045d5a : callq 0x6003c430 = >>> 0x60045d5f : test %eax,%eax >>> 0x60045d61 : jne 0x6004bce4 = >>> 0x60045d67 : add = 0x26d91b2(%rip),%rbx # 0x6271ef20 >>> 0x60045d6e : je 0x6004bce4 = >>> 0x60045d74 : mov $0x3,%edx >>> 0x60045d79 : mov -0x2a8(%rbp),%r14 >>> 0x60045d80 : mov %r14,%rdi >>> 0x60045d83 : mov %r12,%rsi >>> 0x60045d86 : callq 0x6003c430 = >>> 0x60045d8b : test %eax,%eax >>> 0x60045d8d : jne 0x6004bce4 = >>> 0x60045d93 : add = 0x26d9186(%rip),%r14 # 0x6271ef20 >>> 0x60045d9a : mov = -0x294(%rbp),%r10d >>> 0x60045da1 : mov = $0xfffffffffffffff2,%r13 >>> 0x60045da8 : je 0x6004bcf2 = >>> 0x60045dae : mov $0x602b93da,%esi >>> 0x60045db3 : mov %rbx,%rdi >>> 0x60045db6 : callq 0x60230af0 = >>> 0x60045dbb : test %eax,%eax >>> 0x60045dbd : je 0x6004c566 = >>> 0x60045dc3 : mov %rbx,%rdi >>> 0x60045dc6 : callq 0x60158660 >>> 0x60045dcb : mov %rax,%rdi >>> 0x60045dce : mov %r14,%rsi >>> 0x60045dd1 : mov %r12,%rdx >>> 0x60045dd4 : callq 0x60207360 = >>>=20 >>> But note that the "lock_user_string (guest_addr=3D14)" and >>> "do_freebsd_syscall (cpu_env=3D0x860ea3ac0, num=3D58, arg1=3D14," >>> indicate that the "readlink(char *path," is using a really >>> small address for the path string. >>>=20 >>>=20 >>> I've not figured a way for poudriere bulk builds to leave >>> behind the source code automatically. So far I've not >>> looked at the qemu-bsd-user source code. I do build with >>> both debug and optimization turned on via bsd.port.mk >>> having: >>=20 >> The -w option will create a tarball of the work directory if the >> package build fails. I also often use the testport -i option I want = to >> poke around in the WRKDIR after a build. >=20 > I've been using -w right along. But I'd not used testport at all. >=20 > It looks to me like the syscall errno handling is messed > up. The details that I've observed follow. It follows > a simplified sequence of discovery as far a presentation > order goes. >=20 > The looping code is: >=20 > static inline void target_cpu_loop(CPUPPCState *env) > { > CPUState *cs =3D CPU(ppc_env_get_cpu(env)); > target_siginfo_t info; > int trapnr; > target_ulong ret; >=20 > for(;;) { > cpu_exec_start(cs); > trapnr =3D cpu_exec(cs); > cpu_exec_end(cs); > process_queued_cpu_work(cs); >=20 > switch(trapnr) { > . . . > case POWERPC_EXCP_SYSCALL_USER: > /* system call in user-mode emulation */ > /* WARNING: > * PPC ABI uses overflow flag in cr0 to signal an error > * in syscalls. > */ > env->crf[0] &=3D ~0x1; > ret =3D do_freebsd_syscall(env, env->gpr[0], env->gpr[3], = env->gpr[4], > env->gpr[5], env->gpr[6], env->gpr[7], > env->gpr[8], env->gpr[9], env->gpr[10]); > if (ret =3D=3D (target_ulong)(-TARGET_QEMU_ESIGRETURN)) { > /* Returning from a successful sigreturn syscall. > Avoid corrupting register state. */ > break; > } > if (ret > (target_ulong)(-515)) { > env->crf[0] |=3D 0x1; > ret =3D -ret; > } > env->gpr[3] =3D ret; > break; > . . . > } > process_pending_signals(env); > } > } >=20 > The observed env->gpr[3] =3D=3D 14 is from a prior loop > iteration having ret =3D=3D 14 in the: >=20 > env->gpr[3] =3D ret; >=20 > Prior to this were the values (as seen via > lock_user_string): >=20 > guest_addr=3D278408977 > guest_addr=3D2 >=20 > That 2 also came from the prior ret =3D=3D 2 in the: >=20 > env->gpr[3] =3D ret; >=20 > from when the 278408977 was in being attempted. >=20 > For both the ret =3D=3D 2 and ret =3D=3D 14 were from: >=20 > ret =3D -ret; >=20 > so the return values from do_freebsd_syscall were > -2 and -14 (interpreted as signed). >=20 > The return values trace back to the following code, > where TARGET_EFAULT =3D=3D 14 : >=20 > static inline abi_long do_bsd_readlink(CPUArchState *env, abi_long = arg1, > abi_long arg2, abi_long arg3) > { > abi_long ret; > void *p1, *p2; >=20 > LOCK_PATH(p1, arg1); > p2 =3D lock_user(VERIFY_WRITE, arg2, arg3, 0); > if (p2 =3D=3D NULL) { > UNLOCK_PATH(p1, arg1); > return -TARGET_EFAULT; > } > #ifdef __FreeBSD__ > if (strcmp(p1, "/proc/curproc/file") =3D=3D 0) { > CPUState *cpu =3D ENV_GET_CPU(env); > TaskState *ts =3D (TaskState *)cpu->opaque; > strncpy(p2, ts->bprm->fullpath, arg3); > ret =3D MIN((abi_long)strlen(ts->bprm->fullpath), arg3); > } else > #endif > ret =3D get_errno(readlink(path(p1), p2, arg3)); > unlock_user(p2, arg2, ret); > UNLOCK_PATH(p1, arg1); >=20 > return ret; > } >=20 > The 2 is from: >=20 > ret =3D get_errno(readlink(path(p1), p2, arg3)); >=20 > At the time the p1 points to "/etc/malloc.conf": >=20 > (gdb) step=20 > path (name=3D0x10982f11 "/etc/malloc.conf") at util/path.c:173 >=20 > 169 const char *path(const char *name) > 170 { > 171 /* Only do absolute paths: quick and dirty, but should = mostly be OK. > 172 Could do relative by tracking cwd. */ > (gdb)=20 > 173 if (!base || !name || name[0] !=3D '/') > 174 return name; > 175=09 > 176 return follow_path(base, name) ?: name; > 177 } >=20 > (gdb) print base > $8 =3D (struct pathelem *) 0x0 >=20 > So name is returned unchanged. >=20 >=20 > The 2 is in turn from: >=20 > #define __ENOENT 2 /* No such file or = directory */ >=20 >=20 > Overall one oddity is that this code structure > seems to use -ret from: >=20 > ret =3D do_freebsd_syscall(env, env->gpr[0], env->gpr[3], = env->gpr[4], > env->gpr[5], env->gpr[6], env->gpr[7], > env->gpr[8], env->gpr[9], env->gpr[10]); >=20 > to retry the same operation again the next iteration, > but with env->gpr[3] =3D=3D -ret (as ret was on the return > of do_freebsd_syscall ). >=20 > Once abs(ret) =3D=3D 14 it is fully stuck repeating itself. >=20 > I've no clue if: >=20 > env->gpr[3] =3D ret; >=20 > even makes sense here. >=20 > I've not tried to track down the memory leak activity > that is associated. >=20 > Nor have I checked anything for the: >=20 > cpu_exec_start(cs); > trapnr =3D cpu_exec(cs); > cpu_exec_end(cs); > process_queued_cpu_work(cs); >=20 > activity. It likely contributes to why the loop > retries the readlink again (with a junk address > for the path). I do not see activity advancing the emulated program counter as this looping/retrying happens. Nor anything that is adjusting the problematical re-used env->gpr[3] other than the: 516 env->gpr[3] =3D ret; after the negation of ret for the syscall failure handling. This is confirmed by the following: (gdb) bt #0 cpu_tb_exec (cpu=3D0x860e9b8c0, itb=3D0x60723340 = ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:141 #1 0x0000000060039cb5 in cpu_loop_exec_tb (cpu=3D, = tb=3D, last_tb=3D, tb_exit=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:574 #2 cpu_exec (cpu=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:672 #3 0x000000006003c988 in target_cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/ppc/target_arch_cpu.h:139 #4 cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:121 #5 0x000000006003e003 in main (argc=3D, argv=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:516 . . . (gdb) list 569 { 570 uintptr_t ret; 571 int32_t insns_left; 572=09 573 trace_exec_tb(tb, tb->pc); 574 ret =3D cpu_tb_exec(cpu, tb); 575 tb =3D (TranslationBlock *)(ret & ~TB_EXIT_MASK); 576 *tb_exit =3D ret & TB_EXIT_MASK; 577 if (*tb_exit !=3D TB_EXIT_REQUESTED) { 578 *last_tb =3D tb; . . . cpu_tb_exec (cpu=3D0x860e9b8c0, itb=3D0x60723340 = ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:141 141 CPUArchState *env =3D cpu->env_ptr; (gdb) print/x itb->pc $16 =3D 0x1074d784 (gdb) c Continuing. Thread 1 hit Breakpoint 9, cpu_tb_exec (cpu=3D0x860e9b8c0, = itb=3D0x60723340 ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:141 141 CPUArchState *env =3D cpu->env_ptr; . . . (gdb) print/x itb->pc $18 =3D 0x1074d784 (gdb) c Continuing. Thread 1 hit Breakpoint 9, cpu_tb_exec (cpu=3D0x860e9b8c0, = itb=3D0x60723340 ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:141 141 CPUArchState *env =3D cpu->env_ptr; (gdb) print/x itb->pc $19 =3D 0x1074d784 (gdb) c Continuing. Thread 1 hit Breakpoint 9, cpu_tb_exec (cpu=3D0x860e9b8c0, = itb=3D0x60723340 ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:141 141 CPUArchState *env =3D cpu->env_ptr; (gdb) print/x itb->pc $20 =3D 0x1074d784 and so on. So it appears that syscall emulation does not progress the emulated instruction pointer and so the syscall repeats over and over. (I've still not tracked down what is leaking memory during this looping. But that is probably a secodnary concern at this point.) So how does the code get from: 139 trapnr =3D cpu_exec(cs); to (re-)trying the failed syscall (readlink) attempt? (gdb) bt #0 0x00000000601e25c0 in siglongjmp () #1 0x000000006003a1aa in cpu_loop_exit_restore (cpu=3D, = pc=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec-common.c:77 #2 0x00000000600e0eeb in raise_exception_err_ra (env=3D, = exception=3D, error_code=3D0, raddr=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/excp_helper.c:905 #3 helper_raise_exception_err (env=3D, = exception=3D, error_code=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/excp_helper.c:928 #4 0x00000000607233e6 in static_code_gen_buffer () #5 0x0000000060039ffa in cpu_tb_exec (cpu=3D0x860e9b8c0, itb=3D0x60723340= ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:166 #6 0x0000000060039cb5 in cpu_loop_exec_tb (cpu=3D, = tb=3D, last_tb=3D, tb_exit=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:574 #7 cpu_exec (cpu=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:672 #8 0x000000006003c988 in target_cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/ppc/target_arch_cpu.h:139 #9 cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:121 #10 0x000000006003e003 in main (argc=3D, argv=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:516 It does a siglongjmp via helper_raise_execption_err : (gdb) up #1 0x0000000060039ffa in cpu_tb_exec (cpu=3D0x860e9b8c0, itb=3D0x60723340= ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:166 166 ret =3D tcg_qemu_tb_exec(env, tb_ptr); (gdb) list 161 qemu_log_unlock(); 162 } 163 #endif /* DEBUG_DISAS */ 164=09 165 cpu->can_do_io =3D !use_icount; 166 ret =3D tcg_qemu_tb_exec(env, tb_ptr); 167 cpu->can_do_io =3D 1; 168 last_tb =3D (TranslationBlock *)(ret & ~TB_EXIT_MASK); 169 tb_exit =3D ret & TB_EXIT_MASK; 170 trace_exec_tb_exit(last_tb, tb_exit); (gdb) print tb_ptr $11 =3D (uint8_t *) 0x607233c0 = "A\213n\354\205\355\017\214\037" 0x607233c0 : mov -0x14(%r14),%ebp 0x607233c4 : test %ebp,%ebp 0x607233c6 : jl 0x607233eb = 0x607233cc : movq = $0x1074d784,0x3c8(%r14) 0x607233d7 : mov %r14,%rdi 0x607233da : mov $0x203,%esi 0x607233df : xor %edx,%edx 0x607233e1 : callq 0x600e0ed0 = =3D> 0x607233e6 : jmpq 0x6071ef06 = 0x607233eb : mov $0x60723343,%eax 0x607233f0 : jmpq 0x6071ef08 = The exception is exception=3D=3D515 . 515 is the figure matching up with POWERPC_EXCP_SYSCALL_USER . (gdb) stepi helper_raise_exception_err (env=3D0x860ea3ac0, exception=3D515, = error_code=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/excp_helper.c:927 927 { (gdb) bt #0 helper_raise_exception_err (env=3D0x860ea3ac0, exception=3D515, = error_code=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/excp_helper.c:927 #1 0x00000000607233e6 in static_code_gen_buffer () #2 0x0000000060039ffa in cpu_tb_exec (cpu=3D0x860e9b8c0, itb=3D0x60723340= ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:166 #3 0x0000000060039cb5 in cpu_loop_exec_tb (cpu=3D, = tb=3D, last_tb=3D, tb_exit=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:574 #4 cpu_exec (cpu=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:672 #5 0x000000006003c988 in target_cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/ppc/target_arch_cpu.h:139 #6 cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:121 #7 0x000000006003e003 in main (argc=3D, argv=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:516 Later there is: raise_exception_err_ra (env=3D0x860ea3ac0, exception=3D515, = error_code=3D0, raddr=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/excp_helper.c:903 903 cs->exception_index =3D exception; and then: (gdb) s cpu_loop_exit_restore (cpu=3D0x860e9b8c0, pc=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec-common.c:74 74 if (pc) { (gdb) n 77 siglongjmp(cpu->jmp_env, 1); (gdb) n 0x00000000600398e9 in cpu_exec (cpu=3D0x860e9b8c0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:645 645 if (sigsetjmp(cpu->jmp_env, 0) !=3D 0) { (gdb) bt #0 0x00000000600398e9 in cpu_exec (cpu=3D0x860e9b8c0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:645 #1 0x000000006003c988 in target_cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/ppc/target_arch_cpu.h:139 #2 cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:121 #3 0x000000006003e003 in main (argc=3D, argv=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:516 (gdb) n 651 cpu =3D current_cpu; (gdb)=20 652 cc =3D CPU_GET_CLASS(cpu); (gdb)=20 658 cpu->can_do_io =3D 1; (gdb)=20 659 tb_lock_reset(); (gdb)=20 660 if (qemu_mutex_iothread_locked()) { (gdb)=20 661 qemu_mutex_unlock_iothread(); (gdb)=20 666 while (!cpu_handle_exception(cpu, &ret)) { (gdb)=20 679 cc->cpu_exec_exit(cpu); (gdb) n 680 rcu_read_unlock(); (gdb) n 683 } (gdb) n target_cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/ppc/target_arch_cpu.h:140 140 cpu_exec_end(cs); And it sends up back in: 141 process_queued_cpu_work(cs); 142=09 143 switch(trapnr) { . . . 497 case POWERPC_EXCP_SYSCALL_USER: 498 /* system call in user-mode emulation */ 499 /* WARNING: 500 * PPC ABI uses overflow flag in cr0 to signal an = error 501 * in syscalls. 502 */ (gdb)=20 503 env->crf[0] &=3D ~0x1; 504 ret =3D do_freebsd_syscall(env, env->gpr[0], = env->gpr[3], env->gpr[4], 505 env->gpr[5], env->gpr[6], = env->gpr[7], 506 env->gpr[8], env->gpr[9], = env->gpr[10]); 507 if (ret =3D=3D = (target_ulong)(-TARGET_QEMU_ESIGRETURN)) { 508 /* Returning from a successful sigreturn = syscall. 509 Avoid corrupting register state. */ 510 break; 511 } 512 if (ret > (target_ulong)(-515)) { (gdb)=20 513 env->crf[0] |=3D 0x1; 514 ret =3D -ret; 515 } 516 env->gpr[3] =3D ret; 517 break; =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Aug 31 23:37:37 2017 Return-Path: Delivered-To: freebsd-toolchain@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 67425E0AFBD for ; Thu, 31 Aug 2017 23:37:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-94.reflexion.net [208.70.210.94]) (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 288C26CA8B for ; Thu, 31 Aug 2017 23:37:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24732 invoked from network); 31 Aug 2017 23:37:30 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 31 Aug 2017 23:37:30 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Thu, 31 Aug 2017 19:37:30 -0400 (EDT) Received: (qmail 5645 invoked from network); 31 Aug 2017 23:37:29 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 31 Aug 2017 23:37:29 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 0D2E5EC7ED7; Thu, 31 Aug 2017 16:37:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: qemu-ppc64-static and qemu-ppc-static "live-hang" when I attempt use with poudriere; qemu-arm-static and qemu-aarch64-static work From: Mark Millard In-Reply-To: Date: Thu, 31 Aug 2017 16:37:28 -0700 Cc: Mark Linimon , Don Lewis , FreeBSD Toolchain , FreeBSD Ports , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <32379D16-A06E-4BE8-8FC5-C68A8B80E1D2@dsl-only.net> References: <201708302332.v7UNWSVY073465@gw.catspoiler.org> <9B916738-394B-48B7-AA2E-6193F54760B3@dsl-only.net> <85B5ADE0-5573-4E04-8EC3-CB5751C035FF@dsl-only.net> To: Sean Bruno X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 23:37:37 -0000 [I show some of the target/ppc/translate.c source code and related material this time. Not that I know enough to patch it correctly.] On 2017-Aug-31, at 12:13 PM, Mark Millard = wrote: > [Turns out that the emulated program counter is not progressing > for syscall emulation, at least for [some] syscall [failure] cases.] >=20 > On 2017-Aug-30, at 8:43 PM, Mark Millard = wrote: >=20 >> On 2017-Aug-30, at 4:32 PM, Don Lewis = wrote: >>=20 >>> On 30 Aug, Mark Millard wrote: >>>> On 2017-Aug-30, at 4:00 AM, Mark Linimon = wrote: >>>>=20 >>>>> On Wed, Aug 30, 2017 at 03:09:40AM -0700, Mark Millard wrote: >>>>>> It appears that qemu-ppc64-static and qemu-ppc-static from >>>>>> emulators/qemu-user-static are broken. >>>>>=20 >>>>> Correct, and known for some time. (fwiw sparc64 hangs as well.) >>>>=20 >>>> Looks like qemu-ppc64-static is stuck in a loop, calling >>>> repeatedly: >>>>=20 >>>> do_freebsd_syscall (cpu_env=3D0x860ea3ac0, num=3D58, arg1=3D14, = arg2=3D35995509911, arg3=3D1024, arg4=3D268435904, arg5=3D281494784, = arg6=3D35985701568, arg7=3D515, arg8=3D35985668288) >>>> at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/syscall.c:210 >>>> 210 = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/syscall.c: No such file or directory. >>>>=20 >>>> Which is for: >>>>=20 >>>> 58 AUE_READLINK STD { ssize_t readlink(char *path, char = *buf, \ >>>> size_t count); } >>>>=20 >>>> As confirmed by (note the "callq 0x60207360 " ): >>>>=20 >>>> (gdb)=20 >>>> lock_user_string (guest_addr=3D14) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/qemu.h:508 >>>> 508 = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/qemu.h: No such file or directory. >>>>=20 >>>> (gdb) x/64i 0x0000000060045d3e >>>> =3D> 0x60045d3e : callq 0x6004fd20 = >>>> 0x60045d43 : test %rax,%rax >>>> 0x60045d46 : js 0x6004b99c = >>>> 0x60045d4c : inc %rax >>>> 0x60045d4f : mov $0x1,%edx >>>> 0x60045d54 : mov %rbx,%rdi >>>> 0x60045d57 : mov %rax,%rsi >>>> 0x60045d5a : callq 0x6003c430 = >>>> 0x60045d5f : test %eax,%eax >>>> 0x60045d61 : jne 0x6004bce4 = >>>> 0x60045d67 : add = 0x26d91b2(%rip),%rbx # 0x6271ef20 >>>> 0x60045d6e : je 0x6004bce4 = >>>> 0x60045d74 : mov $0x3,%edx >>>> 0x60045d79 : mov -0x2a8(%rbp),%r14 >>>> 0x60045d80 : mov %r14,%rdi >>>> 0x60045d83 : mov %r12,%rsi >>>> 0x60045d86 : callq 0x6003c430 = >>>> 0x60045d8b : test %eax,%eax >>>> 0x60045d8d : jne 0x6004bce4 = >>>> 0x60045d93 : add = 0x26d9186(%rip),%r14 # 0x6271ef20 >>>> 0x60045d9a : mov = -0x294(%rbp),%r10d >>>> 0x60045da1 : mov = $0xfffffffffffffff2,%r13 >>>> 0x60045da8 : je 0x6004bcf2 = >>>> 0x60045dae : mov $0x602b93da,%esi >>>> 0x60045db3 : mov %rbx,%rdi >>>> 0x60045db6 : callq 0x60230af0 = >>>> 0x60045dbb : test %eax,%eax >>>> 0x60045dbd : je 0x6004c566 = >>>> 0x60045dc3 : mov %rbx,%rdi >>>> 0x60045dc6 : callq 0x60158660 >>>> 0x60045dcb : mov %rax,%rdi >>>> 0x60045dce : mov %r14,%rsi >>>> 0x60045dd1 : mov %r12,%rdx >>>> 0x60045dd4 : callq 0x60207360 = >>>>=20 >>>> But note that the "lock_user_string (guest_addr=3D14)" and >>>> "do_freebsd_syscall (cpu_env=3D0x860ea3ac0, num=3D58, arg1=3D14," >>>> indicate that the "readlink(char *path," is using a really >>>> small address for the path string. >>>>=20 >>>>=20 >>>> I've not figured a way for poudriere bulk builds to leave >>>> behind the source code automatically. So far I've not >>>> looked at the qemu-bsd-user source code. I do build with >>>> both debug and optimization turned on via bsd.port.mk >>>> having: >>>=20 >>> The -w option will create a tarball of the work directory if the >>> package build fails. I also often use the testport -i option I want = to >>> poke around in the WRKDIR after a build. >>=20 >> I've been using -w right along. But I'd not used testport at all. >>=20 >> It looks to me like the syscall errno handling is messed >> up. The details that I've observed follow. It follows >> a simplified sequence of discovery as far a presentation >> order goes. >>=20 >> The looping code is: >>=20 >> static inline void target_cpu_loop(CPUPPCState *env) >> { >> CPUState *cs =3D CPU(ppc_env_get_cpu(env)); >> target_siginfo_t info; >> int trapnr; >> target_ulong ret; >>=20 >> for(;;) { >> cpu_exec_start(cs); >> trapnr =3D cpu_exec(cs); >> cpu_exec_end(cs); >> process_queued_cpu_work(cs); >>=20 >> switch(trapnr) { >> . . . >> case POWERPC_EXCP_SYSCALL_USER: >> /* system call in user-mode emulation */ >> /* WARNING: >> * PPC ABI uses overflow flag in cr0 to signal an error >> * in syscalls. >> */ >> env->crf[0] &=3D ~0x1; >> ret =3D do_freebsd_syscall(env, env->gpr[0], env->gpr[3], = env->gpr[4], >> env->gpr[5], env->gpr[6], env->gpr[7], >> env->gpr[8], env->gpr[9], env->gpr[10]); >> if (ret =3D=3D (target_ulong)(-TARGET_QEMU_ESIGRETURN)) { >> /* Returning from a successful sigreturn syscall. >> Avoid corrupting register state. */ >> break; >> } >> if (ret > (target_ulong)(-515)) { >> env->crf[0] |=3D 0x1; >> ret =3D -ret; >> } >> env->gpr[3] =3D ret; >> break; >> . . . >> } >> process_pending_signals(env); >> } >> } >>=20 >> The observed env->gpr[3] =3D=3D 14 is from a prior loop >> iteration having ret =3D=3D 14 in the: >>=20 >> env->gpr[3] =3D ret; >>=20 >> Prior to this were the values (as seen via >> lock_user_string): >>=20 >> guest_addr=3D278408977 >> guest_addr=3D2 >>=20 >> That 2 also came from the prior ret =3D=3D 2 in the: >>=20 >> env->gpr[3] =3D ret; >>=20 >> from when the 278408977 was in being attempted. >>=20 >> For both the ret =3D=3D 2 and ret =3D=3D 14 were from: >>=20 >> ret =3D -ret; >>=20 >> so the return values from do_freebsd_syscall were >> -2 and -14 (interpreted as signed). >>=20 >> The return values trace back to the following code, >> where TARGET_EFAULT =3D=3D 14 : >>=20 >> static inline abi_long do_bsd_readlink(CPUArchState *env, abi_long = arg1, >> abi_long arg2, abi_long arg3) >> { >> abi_long ret; >> void *p1, *p2; >>=20 >> LOCK_PATH(p1, arg1); >> p2 =3D lock_user(VERIFY_WRITE, arg2, arg3, 0); >> if (p2 =3D=3D NULL) { >> UNLOCK_PATH(p1, arg1); >> return -TARGET_EFAULT; >> } >> #ifdef __FreeBSD__ >> if (strcmp(p1, "/proc/curproc/file") =3D=3D 0) { >> CPUState *cpu =3D ENV_GET_CPU(env); >> TaskState *ts =3D (TaskState *)cpu->opaque; >> strncpy(p2, ts->bprm->fullpath, arg3); >> ret =3D MIN((abi_long)strlen(ts->bprm->fullpath), arg3); >> } else >> #endif >> ret =3D get_errno(readlink(path(p1), p2, arg3)); >> unlock_user(p2, arg2, ret); >> UNLOCK_PATH(p1, arg1); >>=20 >> return ret; >> } >>=20 >> The 2 is from: >>=20 >> ret =3D get_errno(readlink(path(p1), p2, arg3)); >>=20 >> At the time the p1 points to "/etc/malloc.conf": >>=20 >> (gdb) step=20 >> path (name=3D0x10982f11 "/etc/malloc.conf") at util/path.c:173 >>=20 >> 169 const char *path(const char *name) >> 170 { >> 171 /* Only do absolute paths: quick and dirty, but should = mostly be OK. >> 172 Could do relative by tracking cwd. */ >> (gdb)=20 >> 173 if (!base || !name || name[0] !=3D '/') >> 174 return name; >> 175=09 >> 176 return follow_path(base, name) ?: name; >> 177 } >>=20 >> (gdb) print base >> $8 =3D (struct pathelem *) 0x0 >>=20 >> So name is returned unchanged. >>=20 >>=20 >> The 2 is in turn from: >>=20 >> #define __ENOENT 2 /* No such file or = directory */ >>=20 >>=20 >> Overall one oddity is that this code structure >> seems to use -ret from: >>=20 >> ret =3D do_freebsd_syscall(env, env->gpr[0], env->gpr[3], = env->gpr[4], >> env->gpr[5], env->gpr[6], env->gpr[7], >> env->gpr[8], env->gpr[9], env->gpr[10]); >>=20 >> to retry the same operation again the next iteration, >> but with env->gpr[3] =3D=3D -ret (as ret was on the return >> of do_freebsd_syscall ). >>=20 >> Once abs(ret) =3D=3D 14 it is fully stuck repeating itself. >>=20 >> I've no clue if: >>=20 >> env->gpr[3] =3D ret; >>=20 >> even makes sense here. >>=20 >> I've not tried to track down the memory leak activity >> that is associated. >>=20 >> Nor have I checked anything for the: >>=20 >> cpu_exec_start(cs); >> trapnr =3D cpu_exec(cs); >> cpu_exec_end(cs); >> process_queued_cpu_work(cs); >>=20 >> activity. It likely contributes to why the loop >> retries the readlink again (with a junk address >> for the path). >=20 > I do not see activity advancing the emulated > program counter as this looping/retrying happens. > Nor anything that is adjusting the problematical > re-used env->gpr[3] other than the: >=20 > 516 env->gpr[3] =3D ret; >=20 > after the negation of ret for the syscall failure > handling. >=20 > This is confirmed by the following: >=20 > (gdb) bt > #0 cpu_tb_exec (cpu=3D0x860e9b8c0, itb=3D0x60723340 = ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:141 > #1 0x0000000060039cb5 in cpu_loop_exec_tb (cpu=3D, = tb=3D, last_tb=3D, tb_exit=3D) > at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:574 > #2 cpu_exec (cpu=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:672 > #3 0x000000006003c988 in target_cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/ppc/target_arch_cpu.h:139 > #4 cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:121 > #5 0x000000006003e003 in main (argc=3D, = argv=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:516 > . . . > (gdb) list > 569 { > 570 uintptr_t ret; > 571 int32_t insns_left; > 572=09 > 573 trace_exec_tb(tb, tb->pc); > 574 ret =3D cpu_tb_exec(cpu, tb); > 575 tb =3D (TranslationBlock *)(ret & ~TB_EXIT_MASK); > 576 *tb_exit =3D ret & TB_EXIT_MASK; > 577 if (*tb_exit !=3D TB_EXIT_REQUESTED) { > 578 *last_tb =3D tb; > . . . > cpu_tb_exec (cpu=3D0x860e9b8c0, itb=3D0x60723340 = ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:141 > 141 CPUArchState *env =3D cpu->env_ptr; > (gdb) print/x itb->pc > $16 =3D 0x1074d784 > (gdb) c > Continuing. >=20 > Thread 1 hit Breakpoint 9, cpu_tb_exec (cpu=3D0x860e9b8c0, = itb=3D0x60723340 ) > at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:141 > 141 CPUArchState *env =3D cpu->env_ptr; > . . . > (gdb) print/x itb->pc > $18 =3D 0x1074d784 > (gdb) c > Continuing. >=20 > Thread 1 hit Breakpoint 9, cpu_tb_exec (cpu=3D0x860e9b8c0, = itb=3D0x60723340 ) > at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:141 > 141 CPUArchState *env =3D cpu->env_ptr; > (gdb) print/x itb->pc > $19 =3D 0x1074d784 > (gdb) c > Continuing. >=20 > Thread 1 hit Breakpoint 9, cpu_tb_exec (cpu=3D0x860e9b8c0, = itb=3D0x60723340 ) > at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:141 > 141 CPUArchState *env =3D cpu->env_ptr; > (gdb) print/x itb->pc > $20 =3D 0x1074d784 >=20 > and so on. >=20 > So it appears that syscall emulation does not progress the > emulated instruction pointer and so the syscall repeats > over and over. >=20 > (I've still not tracked down what is leaking memory > during this looping. But that is probably a secodnary > concern at this point.) >=20 >=20 > So how does the code get from: >=20 > 139 trapnr =3D cpu_exec(cs); >=20 > to (re-)trying the failed syscall (readlink) attempt? >=20 > (gdb) bt > #0 0x00000000601e25c0 in siglongjmp () > #1 0x000000006003a1aa in cpu_loop_exit_restore (cpu=3D, pc=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec-common.c:77 > #2 0x00000000600e0eeb in raise_exception_err_ra (env=3D, exception=3D, error_code=3D0, raddr=3D0) > at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/excp_helper.c:905 > #3 helper_raise_exception_err (env=3D, = exception=3D, error_code=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/excp_helper.c:928 > #4 0x00000000607233e6 in static_code_gen_buffer () > #5 0x0000000060039ffa in cpu_tb_exec (cpu=3D0x860e9b8c0, = itb=3D0x60723340 ) > at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:166 > #6 0x0000000060039cb5 in cpu_loop_exec_tb (cpu=3D, = tb=3D, last_tb=3D, tb_exit=3D) > at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:574 > #7 cpu_exec (cpu=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:672 > #8 0x000000006003c988 in target_cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/ppc/target_arch_cpu.h:139 > #9 cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:121 > #10 0x000000006003e003 in main (argc=3D, = argv=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:516 >=20 > It does a siglongjmp via helper_raise_execption_err : >=20 > (gdb) up > #1 0x0000000060039ffa in cpu_tb_exec (cpu=3D0x860e9b8c0, = itb=3D0x60723340 ) > at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:166 > 166 ret =3D tcg_qemu_tb_exec(env, tb_ptr); > (gdb) list > 161 qemu_log_unlock(); > 162 } > 163 #endif /* DEBUG_DISAS */ > 164=09 > 165 cpu->can_do_io =3D !use_icount; > 166 ret =3D tcg_qemu_tb_exec(env, tb_ptr); > 167 cpu->can_do_io =3D 1; > 168 last_tb =3D (TranslationBlock *)(ret & ~TB_EXIT_MASK); > 169 tb_exit =3D ret & TB_EXIT_MASK; > 170 trace_exec_tb_exit(last_tb, tb_exit); > (gdb) print tb_ptr > $11 =3D (uint8_t *) 0x607233c0 = "A\213n\354\205\355\017\214\037" >=20 > 0x607233c0 : mov -0x14(%r14),%ebp > 0x607233c4 : test %ebp,%ebp > 0x607233c6 : jl 0x607233eb = > 0x607233cc : movq = $0x1074d784,0x3c8(%r14) > 0x607233d7 : mov %r14,%rdi > 0x607233da : mov $0x203,%esi > 0x607233df : xor %edx,%edx > 0x607233e1 : callq 0x600e0ed0 = > =3D> 0x607233e6 : jmpq = 0x6071ef06 > 0x607233eb : mov $0x60723343,%eax > 0x607233f0 : jmpq 0x6071ef08 = >=20 > The exception is exception=3D=3D515 . 515 is the > figure matching up with POWERPC_EXCP_SYSCALL_USER . >=20 > (gdb) stepi > helper_raise_exception_err (env=3D0x860ea3ac0, exception=3D515, = error_code=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/excp_helper.c:927 > 927 { > (gdb) bt > #0 helper_raise_exception_err (env=3D0x860ea3ac0, exception=3D515, = error_code=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/excp_helper.c:927 > #1 0x00000000607233e6 in static_code_gen_buffer () > #2 0x0000000060039ffa in cpu_tb_exec (cpu=3D0x860e9b8c0, = itb=3D0x60723340 ) > at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:166 > #3 0x0000000060039cb5 in cpu_loop_exec_tb (cpu=3D, = tb=3D, last_tb=3D, tb_exit=3D) > at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:574 > #4 cpu_exec (cpu=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:672 > #5 0x000000006003c988 in target_cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/ppc/target_arch_cpu.h:139 > #6 cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:121 > #7 0x000000006003e003 in main (argc=3D, = argv=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:516 >=20 > Later there is: >=20 > raise_exception_err_ra (env=3D0x860ea3ac0, exception=3D515, = error_code=3D0, raddr=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/excp_helper.c:903 > 903 cs->exception_index =3D exception; >=20 > and then: >=20 > (gdb) s > cpu_loop_exit_restore (cpu=3D0x860e9b8c0, pc=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec-common.c:74 > 74 if (pc) { > (gdb) n > 77 siglongjmp(cpu->jmp_env, 1); > (gdb) n > 0x00000000600398e9 in cpu_exec (cpu=3D0x860e9b8c0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:645 > 645 if (sigsetjmp(cpu->jmp_env, 0) !=3D 0) { > (gdb) bt > #0 0x00000000600398e9 in cpu_exec (cpu=3D0x860e9b8c0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:645 > #1 0x000000006003c988 in target_cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/ppc/target_arch_cpu.h:139 > #2 cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:121 > #3 0x000000006003e003 in main (argc=3D, = argv=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:516 > (gdb) n > 651 cpu =3D current_cpu; > (gdb)=20 > 652 cc =3D CPU_GET_CLASS(cpu); > (gdb)=20 > 658 cpu->can_do_io =3D 1; > (gdb)=20 > 659 tb_lock_reset(); > (gdb)=20 > 660 if (qemu_mutex_iothread_locked()) { > (gdb)=20 > 661 qemu_mutex_unlock_iothread(); > (gdb)=20 > 666 while (!cpu_handle_exception(cpu, &ret)) { > (gdb)=20 > 679 cc->cpu_exec_exit(cpu); > (gdb) n > 680 rcu_read_unlock(); > (gdb) n > 683 } > (gdb) n > target_cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/ppc/target_arch_cpu.h:140 > 140 cpu_exec_end(cs); >=20 > And it sends up back in: >=20 > 141 process_queued_cpu_work(cs); > 142=09 > 143 switch(trapnr) { > . . . > 497 case POWERPC_EXCP_SYSCALL_USER: > 498 /* system call in user-mode emulation */ > 499 /* WARNING: > 500 * PPC ABI uses overflow flag in cr0 to signal an = error > 501 * in syscalls. > 502 */ > (gdb)=20 > 503 env->crf[0] &=3D ~0x1; > 504 ret =3D do_freebsd_syscall(env, env->gpr[0], = env->gpr[3], env->gpr[4], > 505 env->gpr[5], env->gpr[6], = env->gpr[7], > 506 env->gpr[8], env->gpr[9], = env->gpr[10]); > 507 if (ret =3D=3D = (target_ulong)(-TARGET_QEMU_ESIGRETURN)) { > 508 /* Returning from a successful sigreturn = syscall. > 509 Avoid corrupting register state. */ > 510 break; > 511 } > 512 if (ret > (target_ulong)(-515)) { > (gdb)=20 > 513 env->crf[0] |=3D 0x1; > 514 ret =3D -ret; > 515 } > 516 env->gpr[3] =3D ret; > 517 break; target/ppc/translate.c has : static inline void gen_update_nip(DisasContext *ctx, target_ulong nip) { if (NARROW_MODE(ctx)) { nip =3D (uint32_t)nip; } tcg_gen_movi_tl(cpu_nip, nip); } =20 static void gen_exception_err(DisasContext *ctx, uint32_t excp, uint32_t = error) { TCGv_i32 t0, t1; =20 /* These are all synchronous exceptions, we set the PC back to * the faulting instruction */ if (ctx->exception =3D=3D POWERPC_EXCP_NONE) { gen_update_nip(ctx, ctx->nip - 4); } t0 =3D tcg_const_i32(excp); t1 =3D tcg_const_i32(error); gen_helper_raise_exception_err(cpu_env, t0, t1); tcg_temp_free_i32(t0); tcg_temp_free_i32(t1); ctx->exception =3D (excp); } . . . #if defined(CONFIG_USER_ONLY) #define POWERPC_SYSCALL POWERPC_EXCP_SYSCALL_USER #else #define POWERPC_SYSCALL POWERPC_EXCP_SYSCALL #endif static void gen_sc(DisasContext *ctx) { uint32_t lev; lev =3D (ctx->opcode >> 5) & 0x7F; gen_exception_err(ctx, POWERPC_SYSCALL, lev); } And there is: Thread 1 hit Breakpoint 10, gen_sc (ctx=3D0x7ffffffe3f48) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/translate.c:3703 3703 lev =3D (ctx->opcode >> 5) & 0x7F; (gdb) bt #0 gen_sc (ctx=3D0x7ffffffe3f48) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/translate.c:3703 #1 0x0000000060064f4b in gen_intermediate_code (env=3D0x860ea3ac0, = tb=3D0x60723280 ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/translate.c:7360 #2 0x000000006003b090 in tb_gen_code (cpu=3D, = pc=3D276092800, cs_base=3D0, flags=3D33579008, cflags=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/translate-all.c:1276 #3 0x0000000060039c14 in tb_find (cpu=3D, = last_tb=3D, tb_exit=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:363 #4 cpu_exec (cpu=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:671 #5 0x000000006003c988 in target_cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/ppc/target_arch_cpu.h:139 #6 cpu_loop (env=3D0x860ea3ac0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:121 #7 0x000000006003e003 in main (argc=3D, argv=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/b= sd-user/main.c:516(gdb) finish Run till exit from #0 gen_sc (ctx=3D0x7ffffffe3f48) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/translate.c:3703 gen_intermediate_code (env=3D0x860ea3ac0, tb=3D0x60723280 = ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/translate.c:7365 7365 if (unlikely(ctx.singlestep_enabled & CPU_SINGLE_STEP && (gdb) finish Run till exit from #0 gen_sc (ctx=3D0x7ffffffe3f48) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/translate.c:3703 gen_intermediate_code (env=3D0x860ea3ac0, tb=3D0x60723280 = ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/translate.c:7365 7365 if (unlikely(ctx.singlestep_enabled & CPU_SINGLE_STEP && (gdb) finish Run till exit from #0 gen_intermediate_code (env=3D0x860ea3ac0, = tb=3D0x60723280 ) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/t= arget/ppc/translate.c:7365 tb_gen_code (cpu=3D, pc=3D276092800, cs_base=3D0, = flags=3D33579008, cflags=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/translate-all.c:1277 1277 tcg_ctx.cpu =3D NULL; (gdb) finish Run till exit from #0 tb_gen_code (cpu=3D, pc=3D276092800,= cs_base=3D0, flags=3D33579008, cflags=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/translate-all.c:1277 0x0000000060039c14 in tb_find (cpu=3D, last_tb=3D, tb_exit=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/a= ccel/tcg/cpu-exec.c:363 363 tb =3D tb_gen_code(cpu, pc, cs_base, flags, 0); Value returned is $23 =3D (TranslationBlock *) 0x60723280 = Note that the: 0x607233cc : movq = $0x1074d784,0x3c8(%r14) is the emulated PC being forced to point back to the same syscall instruction again, generated via gen_update_nip(ctx, ctx->nip - 4) . The gen_sc instance (the first) seems to be responsible for: 0x607233cc : movq = $0x1074d784,0x3c8(%r14) 0x607233d7 : mov %r14,%rdi 0x607233da : mov $0x203,%esi 0x607233df : xor %edx,%edx 0x607233e1 : callq 0x600e0ed0 = =3D> 0x607233e6 : jmpq 0x6071ef06 = 0x607233eb : mov $0x60723343,%eax 0x607233f0 : jmpq 0x6071ef08 = being generated as its callers "finish" (see above). (helper_raise_exception_err leads to siglongjmp so the call does not return.) If I interpret everything right, even for a successful readlink (or other syscall) the emulated PC would not be updated to the next instruction and the code would loop, repeating the syscall. It appears to me that something is wrong with the logic: static void gen_exception_err(DisasContext *ctx, uint32_t excp, uint32_t = error) { TCGv_i32 t0, t1; =20 /* These are all synchronous exceptions, we set the PC back to * the faulting instruction */ if (ctx->exception =3D=3D POWERPC_EXCP_NONE) { gen_update_nip(ctx, ctx->nip - 4); } . . . or some balancing action is needed later for the likes of readlink once it has completed the (in this case): ret =3D get_errno(readlink(path(p1), p2, arg3)); In fact for the early return (the -14 case) that avoids the call t readlink the loop happens as stands: LOCK_PATH(p1, arg1); p2 =3D lock_user(VERIFY_WRITE, arg2, arg3, 0); if (p2 =3D=3D NULL) { UNLOCK_PATH(p1, arg1); return -TARGET_EFAULT; } So either the emulated PC should progress for the early return or some other handling should be involved for it: neither continuing to the next instruction nor repeating the instruction would seem appropriate. I expect that this is a separate issue from the readlink-used case as far as correct handling goes. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Sep 2 16:42:44 2017 Return-Path: Delivered-To: freebsd-toolchain@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 7BCCEE1B862 for ; Sat, 2 Sep 2017 16:42:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 6A0116890C for ; Sat, 2 Sep 2017 16:42:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v82GghKT021929 for ; Sat, 2 Sep 2017 16:42:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 221588] clang crashes when compiling cad/openvsp Date: Sat, 02 Sep 2017 16:42:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: fernando.apesteguia@gmail.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2017 16:42:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221588 fernando.apesteguia@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |Overcome By Events --- Comment #4 from fernando.apesteguia@gmail.com --- Closing the PR since I opened another one with an update of the port so it compiles in -CURRENT. See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222001 I tested the unpatched port with clang 5.0.0 r312293 and clang still crashe= s. I didn't see a but report in llvm's bugzilla. Has this been reported? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Sep 2 18:01:46 2017 Return-Path: Delivered-To: freebsd-toolchain@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 8967AE1EEE0 for ; Sat, 2 Sep 2017 18:01:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 72BB66B7D3 for ; Sat, 2 Sep 2017 18:01:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v82I1jWm026233 for ; Sat, 2 Sep 2017 18:01:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 221588] clang crashes when compiling cad/openvsp Date: Sat, 02 Sep 2017 18:01:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2017 18:01:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221588 --- Comment #5 from Dimitry Andric --- (In reply to fernando.apesteguia from comment #4) > Closing the PR since I opened another one with an update of the port so it > compiles in -CURRENT. See: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222001 >=20 > I tested the unpatched port with clang 5.0.0 r312293 and clang still > crashes. I didn't see a but report in llvm's bugzilla. Has this been > reported? No, this code makes no sense, so it also makes no real sense to report it. = Just apply the patch. --=20 You are receiving this mail because: You are the assignee for the bug.=