From owner-freebsd-toolchain@freebsd.org Mon Oct 22 21:35:41 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCD32FD7D1A; Mon, 22 Oct 2018 21:35:40 +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 4174B7579C; Mon, 22 Oct 2018 21:35:40 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id BDA6710AFCD; Mon, 22 Oct 2018 17:35:38 -0400 (EDT) Subject: Re: Reasons to still not build buildworld buildkernel via system-clang --John Baldwin notes one I was unaware of To: Mark Millard , FreeBSD Toolchain , Sean Fertile References: <23400842-E5CB-4251-BFE5-78D524A64012@yahoo.com> Cc: Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML From: John Baldwin Message-ID: Date: Mon, 22 Oct 2018 14:35:37 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 22 Oct 2018 17:35:39 -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.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 21:35:41 -0000 On 10/19/18 7:23 AM, Mark Millard wrote: > [I'm adding toolchain and John B. to the TO: list. John B. > may want to reply to Sean F. I'm also adding a > /lib/libgcc_s.so related item to the list of 3 known > issues.] > >> On 2018-Oct-19, at 6:21 AM, Sean Fertile wrote: >> >> Clang isn't getting the tls model wrong, it actually generates pic code by default as if -fpic were specified. I think the original intent behind switching >> to pic by default was due to incorrectly thinking gcc was pic by default (I'm not sure if this was meant as only gcc on BSD or gcc on powerpc64 in general), >> as well as working around some problems that clangs non-pic codegen has/had for the ELF V1 abi. There are some patches on phabricator for switching >> the default back to non-pic codegen, but they leave the pic default for BSD: https://reviews.llvm.org/D53384 and https://reviews.llvm.org/D53383 >> >> According to what you and John are saying the pic default is incorrect for BSD as well. If thats the case please either comment on the reviews to let Stefan know, >> or let me know here and we can update the patches accordingly. No, what I am saying is that in GCC, the decision for dynamic TLS model vs static TLS model is based on whether or not -fPIC is explicitly given on the command line. For MIPS at least (where I am familiar with this), both GCC and clang default to implicit PIC. However, GCC uses static TLS models (initial-exec, etc.) when -fPIC isn't given on the command line even if PIC is still implicitly enabled. It only uses the dynamic TLS models (intended for use in shared libraries) if -fPIC is explicitly passed on the command line. However, clang implements implicit PIC by passing the equivalent of -fPIC to the llvm backend, so on MIPS at least, the result is that llvm _always_ uses the dynamic TLS models including for static libraries and binaries where this is wrong. I have some patches from one of the LLVM MIPS folks that kind of hackishly fix this, but by adding a new flag only for MIPS. I wanted to adjust their patches to be more generic so that there's a new '-mshared-library' or some such passed from clang to llvm and have clang only set that to true if -fPIC is explicitly given on the command line to match GCC's behavior. So to be clear, this isn't saying that the implicit PIC setting is wrong. It is saying that the llvm backend incorrectly interprets the clang front-end's implicit PIC setting as being an explicit PIC setting for the purposes of choosing the TLS model to use. -- John Baldwin From owner-freebsd-toolchain@freebsd.org Mon Oct 22 22:28:21 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05DA3FD9723 for ; Mon, 22 Oct 2018 22:28:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 95B1A77869 for ; Mon, 22 Oct 2018 22:28:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5A25DFD9714; Mon, 22 Oct 2018 22:28:20 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48E69FD9713 for ; Mon, 22 Oct 2018 22:28:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF57E77868 for ; Mon, 22 Oct 2018 22:28:19 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 1974ADD4B for ; Mon, 22 Oct 2018 22:28:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9MMSI25085835 for ; Mon, 22 Oct 2018 22:28:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9MMSI6O085834 for toolchain@FreeBSD.org; Mon, 22 Oct 2018 22:28:18 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 220822] Missing libatomic.a for clang? Date: Mon, 22 Oct 2018 22:28:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: 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: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: blocked 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.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 22:28:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220822 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |232546 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232546 [Bug 232546] www/firefox-esr: 60.3.0,1 fails with linker_error with TEST=3D= on --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Oct 23 21:15:09 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05768FFD1AF for ; Tue, 23 Oct 2018 21:15:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-22.consmr.mail.ne1.yahoo.com (sonic304-22.consmr.mail.ne1.yahoo.com [66.163.191.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 925D470BBC for ; Tue, 23 Oct 2018 21:15:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: YCcHGaoVM1lXw9D9t78UlsECVl173YrkE0iHZihgZsKe9HPii4qsJimayYMupAB pPHnD6FLxiWgCRlECgLFk4vXNzd8.JGozzRXKoYlCIWIBixlPEb0ccAELX.cEGPMnoxVC_PZ8qiG d0xRKz4pt9fMfsVPkLfOQvjIvb_L0BZTTsMj3eCgRMk3E5Sfehwe1ZuCh1iY.tvUBZA7260V0ubB RXmuTI9Qoc.0BYMEZnEoQYS2bwVOQD4iiCRopVg40G.YG_CuqqVEsyCVAnjSzvs2rbks4wOPBh_G _w9g6btZmxDE0gXWUAv55mXsKHPBBGxudSsao.pa.D4SclWK7S2YiLjXHH.d2w3J8KhXORRWw4bX fr1RdGbDsruW32ZxUizI1K.tAGz4NzsQUcbVOPP8uGc43fqaXQaSeuiZT3iaj2c3wcxD80g5bXYP OvceoOnUMpLXg8ZqiBWyw3gW895WvihBNGpMMisDfQTdsGDZkR2K3POm21VMsN2szqRCviA1ZvfM HnfoS3B._Yz2WjxbtIhFcASKD4HJT3QFP.Qy.Qxzu4FPL_1TOooDtl2xioRODgjR9i_4JXhdgw8v NaKwoDfcNxcgslc1mJgIeUnaXzlxRnNI22WSAqryzuNKlb6KA2kDoMl13WveThs.zBX8HP3GMQh1 RSj4Jm08leN8TV4MRvh3r8VHisYGLltQvxlwJJFCbQRmgthNOoWRRlkPxYb4gNTOXifkpjFWzxwN GKIT.VzFxycd2k9E93V7vTgMcYF77.uwXtNcuBRpqA2KTU96lFszckhsmzCiJWzdPUlC_xemnHuT gIK6Oc93Lv7dHBw_Ek5bWB2nJQXQowwbCZ7cCQX8dlq_3i7rGOK4au50Wbym4t4RLQG1yb1BPUfm RFzazHnZ_ToLVHXmdby3ukXydP0reYAfKOoLnvgimVNvHeMn6DXgCZenz5FMe5OZ2Lfp0bdl1zkY Ywxc3ZProbTyVzDsSDMSDr6rSAADYv6K0hTwwCKaWJBdEE4nkChaSsRAvBOdoNHoN_PT1szysV30 DcFNmsjTZKWoJ2.VLgEQ.E7bRzUDZ4yOm.g3Q4JVFLg1ezQhsHOuXee13KHE1Djetu6yr3NjCD9S fJ41YEok- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Tue, 23 Oct 2018 21:15:00 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp413.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0aa92ced50a486c022d21f2e083dfa26; Tue, 23 Oct 2018 21:14:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Reasons to still not build buildworld buildkernel via system-clang --John Baldwin notes one I was unaware of From: Mark Millard In-Reply-To: Date: Tue, 23 Oct 2018 14:14:56 -0700 Cc: FreeBSD Toolchain , Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML , John Baldwin Content-Transfer-Encoding: quoted-printable Message-Id: References: <23400842-E5CB-4251-BFE5-78D524A64012@yahoo.com> To: Sean Fertile X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 21:15:09 -0000 [Mostly just giving some powerpc64 detail, at least when base/binutils is used.] On 2018-Oct-22, at 2:35 PM, John Baldwin wrote: > On 10/19/18 7:23 AM, Mark Millard wrote: >> [I'm adding toolchain and John B. to the TO: list. John B. >> may want to reply to Sean F. I'm also adding a >> /lib/libgcc_s.so related item to the list of 3 known >> issues.] >>=20 >>> On 2018-Oct-19, at 6:21 AM, Sean Fertile = wrote: >>>=20 >>> Clang isn't getting the tls model wrong, it actually generates pic = code by default as if -fpic were specified. I think the original intent = behind switching=20 >>> to pic by default was due to incorrectly thinking gcc was pic by = default (I'm not sure if this was meant as only gcc on BSD or gcc on = powerpc64 in general),=20 >>> as well as working around some problems that clangs non-pic codegen = has/had for the ELF V1 abi. There are some patches on phabricator for = switching >>> the default back to non-pic codegen, but they leave the pic default = for BSD: https://reviews.llvm.org/D53384 and = https://reviews.llvm.org/D53383 >>>=20 >>> According to what you and John are saying the pic default is = incorrect for BSD as well. If thats the case please either comment on = the reviews to let Stefan know, >>> or let me know here and we can update the patches accordingly. >=20 > No, what I am saying is that in GCC, the decision for dynamic TLS = model > vs static TLS model is based on whether or not -fPIC is explicitly > given on the command line. For MIPS at least (where I am familiar = with > this), both GCC and clang default to implicit PIC. FYI: John discovered that mips64/powerpc64 is the context for PIC being the default for clang (I'm ignoring x86_64, Windows, MachO and MacOSX in my comments): bool Generic_GCC::isPICDefault() const { switch (getArch()) { case llvm::Triple::x86_64: return getTriple().isOSWindows(); case llvm::Triple::ppc64: case llvm::Triple::ppc64le: return !getTriple().isOSBinFormatMachO() && !getTriple().isMacOSX(); case llvm::Triple::mips64: case llvm::Triple::mips64el: return true; default: return false; } } > However, GCC uses > static TLS models (initial-exec, etc.) when -fPIC isn't given on the > command line even if PIC is still implicitly enabled. It only uses = the > dynamic TLS models (intended for use in shared libraries) if -fPIC is > explicitly passed on the command line. > However, clang implements implicit PIC by passing the equivalent of > -fPIC to the llvm backend, so on MIPS at least, the result is that = llvm > _always_ uses the dynamic TLS models including for static libraries = and > binaries where this is wrong. I have some patches from one of the = LLVM > MIPS folks that kind of hackishly fix this, but by adding a new flag > only for MIPS. I wanted to adjust their patches to be more generic so > that there's a new '-mshared-library' or some such passed from clang > to llvm and have clang only set that to true if -fPIC is explicitly > given on the command line to match GCC's behavior. >=20 > So to be clear, this isn't saying that the implicit PIC setting is > wrong. It is saying that the llvm backend incorrectly interprets > the clang front-end's implicit PIC setting as being an explicit PIC > setting for the purposes of choosing the TLS model to use. For powerpc64 things are somewhat different via some link-time optimizations when base/binutils is in use (lld not being ready for use for powerpc64 as I understand). (I've no clue what would happen with lld.) cc -g -O2 -c will produce .o files with the __tls_get_addr calls, for example (source shown later): # objdump -r tlsy.o | grep __tls_get_addr 0000000000000024 R_PPC64_REL24 __tls_get_addr 0000000000000038 R_PPC64_REL24 __tls_get_addr # objdump -r tls_main.o | grep __tls_get_addr 0000000000000020 R_PPC64_REL24 __tls_get_addr 0000000000000034 R_PPC64_REL24 __tls_get_addr 000000000000008c R_PPC64_REL24 __tls_get_addr 00000000000000a0 R_PPC64_REL24 __tls_get_addr This is as John indicated. But the likes of: # cc -g -O0 tls_main.o tlsy.o tls.o ends up with a.out having r13 use and no such subroutine calls to __tls_get_addr in x, y, or main. There are some nop instructions from where substitutions were made. It appears that mips64 does not have such a late-optimization in John's context: the __tls_get_addr use survives into a.out as I understand. The source for the example used above was: # more tls.c int __thread i =3D 3; int __thread j =3D 2; # more tlsy.c extern int __thread i; extern int __thread j; int y() { return i+j; } # more tls_main.c extern int __thread i; extern int __thread j; extern int y(); int x() { return i+j; } int main () { return x()-y(); } (So main got some inlining of x() in order for the tls_main.o to show 4 R_PPC64_REL24 uses for __tls_get_addr .) I have no clue if the late-optimization for powerpc64 covers all the cases where direct use of some static TLS model would be appropriate. I just know that, at least in some types of contexts, some calls to __tls_get_addr are eliminated at link time when base/binutils is in use. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Fri Oct 26 21:20:49 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CCA141088EBD for ; Fri, 26 Oct 2018 21:20:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 627566B057 for ; Fri, 26 Oct 2018 21:20:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id BC2291088EA8; Fri, 26 Oct 2018 21:20:43 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A92C1088EA7 for ; Fri, 26 Oct 2018 21:20:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D6EF6AFA2 for ; Fri, 26 Oct 2018 21:20:43 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 4C8EC6AA0 for ; Fri, 26 Oct 2018 21:20:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9QLKZi8090526 for ; Fri, 26 Oct 2018 21:20:35 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9QLKZHg090523 for toolchain@FreeBSD.org; Fri, 26 Oct 2018 21:20:35 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 231355] Compiler assert error when compiling lang/qt5-qml Date: Fri, 26 Oct 2018 21:20:35 +0000 X-Bugzilla-Reason: CC 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: commit-hook@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: mfc-stable11+ 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.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 21:20:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231355 --- Comment #4 from commit-hook@freebsd.org --- A commit references this bug: Author: dim Date: Fri Oct 26 21:20:07 UTC 2018 New revision: 483054 URL: https://svnweb.freebsd.org/changeset/ports/483054 Log: Add all patches from base llvm/clang/lld/lldb 6.0 to devel/llvm60 This adds all the patches that were applied in the past to head, under contrib/llvm. After these, there only minimal diffs left between the port sources and the base sources. Most of these remaining diffs are due to #ifdef shortcuts in the base sources, because we don't compile certain features in. Other diffs are because the port has applied a few changes that we don't have in base. While here, use Makefile.LICENSE from the devel/llvm-devel port. Approved by: brooks (maintainer) Reviewed by: brooks PR: 212343, 225128, 225471, 226388, 226658, 226872, 229050, 230= 444, 230604, 231355 MFH: 2018Q4 Differential Revision: https://reviews.freebsd.org/D17702 Changes: head/devel/llvm60/Makefile head/devel/llvm60/files/clang/patch-head-r331066.diff head/devel/llvm60/files/clang/patch-head-r336227.diff head/devel/llvm60/files/clang/patch-head-r338697.diff head/devel/llvm60/files/clang/patch-head-r339019.diff head/devel/llvm60/files/lld/ head/devel/llvm60/files/lld/patch-head-r331731.diff head/devel/llvm60/files/lld/patch-head-r333401.diff head/devel/llvm60/files/lld/patch-head-r336664.diff head/devel/llvm60/files/lld/patch-head-r336972.diff head/devel/llvm60/files/lld/patch-head-r337282.diff head/devel/llvm60/files/lld/patch-head-r338251.diff head/devel/llvm60/files/lld/patch-head-r338682.diff head/devel/llvm60/files/lld/patch-head-r339013.diff head/devel/llvm60/files/lld/patch-head-r339304.diff head/devel/llvm60/files/lldb/ head/devel/llvm60/files/lldb/patch-head-r332849.diff head/devel/llvm60/files/lldb/patch-head-r332965.diff head/devel/llvm60/files/patch-head-r308867.diff head/devel/llvm60/files/patch-head-r330686.diff head/devel/llvm60/files/patch-head-r331065.diff head/devel/llvm60/files/patch-head-r331366.diff head/devel/llvm60/files/patch-head-r336969.diff head/devel/llvm60/files/patch-head-r336970.diff head/devel/llvm60/files/patch-head-r337615.diff head/devel/llvm60/files/patch-head-r338689.diff --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Oct 27 03:42:40 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58D0410D5E73 for ; Sat, 27 Oct 2018 03:42:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-22.consmr.mail.ne1.yahoo.com (sonic306-22.consmr.mail.ne1.yahoo.com [66.163.189.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E4A9F7A8A5 for ; Sat, 27 Oct 2018 03:42:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: zwJnZtgVM1mOGeludfG9oWedVFYUTG_HiFweCrfJxeEb_8qlDSCiXVZSxzANXXT Ao9YIfs2.9b97JIjVPCkK.d0XWBdtD039da.gNkHUkYPM3b8xVbxpQM9ZcUajWnGRYJ7WwgpNB4B i97vo25sPnxDkF5szOHq51ZlBk3DkOnxUV8_2Xo.3KeSkOqlb5oPpZaYVFWb3zxfIeouEdBzwcec 1xMUq.znqLql9URk_mWl2s9IUSKTX.Hwa.OOn8VNM9ApBcLvezcj68a8yKaLjrfIpggMXxqySDiz HblhdPlUq8JOHY_nJddx.5uO3I_d4bJNpczwFb03JAEE7qzzu9oTHB2bmxXSkwXDvy2bOSCanEAa DSZs0MMVQI7.Si49kowURiqcW_.TLVfKXLmSqqPgU2rsFBJ5EOQNE0Yt7TynURSySEEtoqiGYDNN yNIrEFJFeT3PnaNmVNzJcXq512A6ev76bZ.liIPeng7MFDdQAfcYckrIDwywSG071X4BSr9_JXCP 2.Uzbma2QtyQQf3eXH6cwTKrITAe.JymyodWzRYscEdFUa.1mRQYUPVVkLp0zKTY9qI2ASN028Ef 06Tgxm1rV1hE2iEk..YN6Q7PB.iLiAj5hGNq7grRkgfnOvn0Z7Zl8hAI78RYXhMo.L9afhLLh4ZC qGbJsW8MtByle.I8ZTn87fq4VUGETdHqcqbFavgSCDEb2SvCG7WCl2i_VeHGXKlUG5QhXKsfQoc_ Xo1lEscWwVGL_QOVM_PY_rrf7CO86PF2j5vLqP3vn2cnzumDvK9qnUeUuHqXXh.cBuwt4gX5PaNc IjK6JtAR8ilsc1yWk4PkiqQ0ZJiPz81zEvKWDtMdXjBUffQM45I__7NAvZABuqNg6n.E7O9Resge O9ViEqj45fSmG88KgUwysiIK2XZPAFH9.kjC1ButvrCBgSnpnGhvR_1fyJ6CG5avKeeQiZbXhnuK 6eO3ZVQ3t2Fyig83MSansUyxuvOQ3xhMzA1VLKNzBWnIZw69pRbC605EXfOJXKkMBpj8PyrYGbu7 ShnoCJwdsMmAm0ifFHXdSYjLBnt4QURy0BeYJxuZa0.Y- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Sat, 27 Oct 2018 03:42:33 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp420.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 3e151b3eb4af58016b2110c5cbe634ff; Sat, 27 Oct 2018 03:42:28 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: head -r339076 amd64 -> armv7 port cross build attempt with native tools involved: hangs between a cc (wait) and its child ld (uwait) Message-Id: <33C58480-1E76-4748-83B4-CB39FAD8584A@yahoo.com> Date: Fri, 26 Oct 2018 20:42:27 -0700 To: FreeBSD Toolchain , freeBSD X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 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, 27 Oct 2018 03:42:40 -0000 In trying to amd64 -> armv7 cross build ports via poudriere-devel use with native cross tools involved (and UFS, not ZFS), I'm getting about 117 ports that built and then one that ends up stuck in wait/uwait . ^C to poudriere and restarting it repeats the stuck behavior at the same point (a cc and its ld), for example: [00:02:51] [01] [00:00:00] Building print/texinfo | texinfo-6.5,1 ps output extraction (blank lines added for each of scanning): UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND . . . 0 42312 32181 0 52 0 12904 3904 select I 1 0:00.02 sh: = poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg (texinfo-6.5,1) (sh) 0 42974 42312 0 52 0 12904 3900 wait I 1 0:00.00 sh: = poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg (texinfo-6.5,1) (sh) 0 42975 42974 0 52 0 10408 1840 wait IJ 1 0:00.01 = /usr/bin/make -C /usr/ports/print/texinfo configure 0 43077 42975 0 52 0 10252 1792 wait IJ 1 0:00.00 /bin/sh = -e -c (cd /wrkdirs/usr/ports/print/texinfo/work/texinfo-6.5 && = _LATE_CONFIGURE_ARGS=3D"" ; if [ -z "" ] && ./configure --help=20 0 43375 43077 0 52 0 11164 2392 wait IJ 1 0:00.19 /bin/sh = ./configure --enable-nls --prefix=3D/usr/local --localstatedir=3D/var = --mandir=3D/usr/local/man --disable-silent-rules --infodir=3D/usr 0 46850 43375 0 52 0 11164 2388 wait IJ 1 0:00.00 /bin/sh = ./configure --enable-nls --prefix=3D/usr/local --localstatedir=3D/var = --mandir=3D/usr/local/man --disable-silent-rules --infodir=3D/usr 0 46857 46850 0 52 0 11080 2060 wait IJ 1 0:00.04 /bin/sh = ./configure --disable-option-checking --prefix=3D/usr/local --enable-nls = --localstatedir=3D/var --mandir=3D/usr/local/man --disable-s 0 47796 46857 0 52 0 113840 26184 wait IJ 1 0:00.15 = /usr/local/bin/qemu-arm-static /usr/bin/cc -o conftest -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -mcpu=3Dcortex-a= 0 47801 47796 0 52 0 285300 39672 uwait IJ 1 0:00.22 = qemu-arm-static -L /usr/gnemul/qemu-arm /usr/bin/ld --eh-frame-hdr = -dynamic-linker /libexec/ld-elf.so.1 --hash-style=3Dboth --enable-new- So the "/usr/local/bin/qemu-arm-static /usr/bin/cc . . ." creates the child "qemu-arm-static -L /usr/gnemul/qemu-arm /usr/bin/ld . = . ." process and the two get hung up. Letting it sit for long periods does not let it progress. The full commands are (note the "-pipe" vs. the = "/tmp/conftest-6c0832.o"): /usr/local/bin/qemu-arm-static /usr/bin/cc -o conftest -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG conftest.c and: qemu-arm-static -L /usr/gnemul/qemu-arm /usr/bin/ld --eh-frame-hdr = -dynamic-linker /libexec/ld-elf.so.1 --hash-style=3Dboth = --enable-new-dtags -o conftest /usr/lib/crt1.o /usr/lib/crti.o = /usr/lib/crtbegin.o -L/usr/lib /tmp/conftest-6c0832.o -lgcc --as-needed = -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed = /usr/lib/crtend.o /usr/lib/crtn.o For reference for /tmp/conftest-6c0832.o : # ls -lTd = /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/01/tmp/conftest-6c0= 832.o -rw-r--r-- 1 root wheel 4204 Oct 26 17:33:13 2018 = /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/01/tmp/conftest-6c0= 832.o (I'm not using tmpfs or the like at all.) The context is based on head -r339076 an is on a Ryzen Threadripper 1950X system, natively booted (not Hyper-V). (I've not tried under Hyper-V yet.) Note: I have built ports similarly before --but the last time was back in March-May sometime. # poudriere jail -jFBSDFSSDjailArmV7 -i Jail name: FBSDFSSDjailArmV7 Jail version: 12.0-ALPHA8 Jail arch: arm.armv7 Jail method: null Jail mount: /usr/obj/DESTDIRs/clang-armv7-installworld-poud Jail fs: =20 Jail updated: 2018-10-26 16:42:55 Tree name: default Tree method: null Status: parallel_build: Building started: 2018-10-26 17:29:36 Elapsed time: 02:47:50 Packages built: 0 Packages failed: 0 Packages ignored: 0 Packages skipped: 0 Packages total: 84 Packages left: 84 # poudriere ports -l PORTSTREE METHOD TIMESTAMP PATH default null 2017-08-14 21:07:05 /usr/ports I have yet to think of a way to look into this or to work around it. But my long running build on an Orange Pi Plus 2nd Edition has finished so I'll update from that for now. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Sat Oct 27 05:45:52 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C40B10DA473 for ; Sat, 27 Oct 2018 05:45:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.ne1.yahoo.com (sonic306-20.consmr.mail.ne1.yahoo.com [66.163.189.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C731E7F1C9 for ; Sat, 27 Oct 2018 05:45:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: eAgNwj0VM1lV.s3oma3eYiRCYQUgZBrXptdJggPrgrWrtxYriJkJ.qE9V1GVUTF 6yFJdp1Sm01EvcWJagoLQxvkBgFyAxr5vp0coTSkrU8esC7lDIR.LmyC1qS7oFzJ838nll0ieSAh 93tOlFVYm9x6J_56n6Bh7JgzRqA6SLZUQ8cRmucnp1aHe4ZLjD2QqQFp7Ecv2ytUet56oRKCjPW0 BaJ94utXJZVnuZfy5wLBu_Z9DKXjbyYaU1fG9Tq4bM_1Myf3xm4a2w9tRKl8X2EbdR1_.Vn0vaDd wWhCC4B3.wwpImNe8bxCbwYfVrYEUPQOMK5YAOTR6nQyT3Dk3BGGSaoSXXKMYw69SaOPhOnRz3un xDr1nizhRZE99Jxu4XnLgIrksePXEg3F2VqxDL2cF1y8YzVZlxqE5g6BZydLPAULeMxrZa6f_Ukx OvkTlSirfpsF9VNwlUkuSdioaPOQaQmOuyqPupJm7WEDnZDKzaWSBIt8ftYLCYQf_LgG7S6Rk5vb yjqz6w5y7zi1LbNDxJrfFoqc.svmkjm97ppfJwmvKmkBzGFOgm4jxuQBamY6b0JNXBVsnge_NlT7 4S40MR7.Ot0MohBYRzgN__us1mDeLAbYp.iBVt5Orz963rqHj.7CtLPDjp21JHqRSvOLgcy0SYyy xZ3kJd.XshDFErueOsSKvResL34b58N9IiRRJaqBs0KsylQnGQGoysb8wTy3.nTvfu6_A.dZ6dQd JlBcuueul7kJfIdycOz.5zrGuGMjyLjJgOvl5xgu0ITTOkqU1cVuh4uxYodDVwcBl3XgDswk9DER 0FBNP1qaooGSDnYV9H9dH.mHrSoJSOhIBGP7q2hodOSY3gEVWatPEPM1Ifx33jzPYtcqgbYUpDae 5U0lar7peSOoltCCtEFdFEYDYsFScF3D1HeQFk9J2z5mQWNrnhaWEvyFwUznHuOzdbo9sW750K.b S_X6D.BdsvdeIesgxLt2_xhRsuESYrC9_7XuzcUHCVsL2SexYIKg99uT.sWKMw2CSiv6iIaXwa1w 63LGTLIFLyW2taW23ulzZQxb6Ts02gX35Z1Q9fAnykbCPkOkZ Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Sat, 27 Oct 2018 05:45:44 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp405.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9d2efef407054cbd30f5dde6666a65ef; Sat, 27 Oct 2018 05:35:35 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r339076 amd64 -> armv7 port cross build attempt with native tools involved: hangs between a cc (wait) and its child ld (uwait) Date: Fri, 26 Oct 2018 22:35:33 -0700 References: <33C58480-1E76-4748-83B4-CB39FAD8584A@yahoo.com> To: FreeBSD Toolchain , freeBSD In-Reply-To: <33C58480-1E76-4748-83B4-CB39FAD8584A@yahoo.com> Message-Id: <78DBB85A-44C5-42CF-88F2-79E75E93CF33@yahoo.com> X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 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, 27 Oct 2018 05:45:52 -0000 [Attaching to the ld process with gdb and detaching let things continue.] On 2018-Oct-26, at 8:42 PM, Mark Millard wrote: > In trying to amd64 -> armv7 cross build ports via poudriere-devel > use with native cross tools involved (and UFS, not ZFS), I'm > getting about 117 ports that built and then one that ends up stuck > in wait/uwait . ^C to poudriere and restarting it repeats the > stuck behavior at the same point (a cc and its ld), for example: >=20 >=20 > [00:02:51] [01] [00:00:00] Building print/texinfo | texinfo-6.5,1 >=20 > ps output extraction (blank lines added for each of > scanning): >=20 > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME = COMMAND > . . . > 0 42312 32181 0 52 0 12904 3904 select I 1 0:00.02 sh: = poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg (texinfo-6.5,1) (sh) > 0 42974 42312 0 52 0 12904 3900 wait I 1 0:00.00 sh: = poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg (texinfo-6.5,1) (sh) > 0 42975 42974 0 52 0 10408 1840 wait IJ 1 0:00.01 = /usr/bin/make -C /usr/ports/print/texinfo configure > 0 43077 42975 0 52 0 10252 1792 wait IJ 1 0:00.00 /bin/sh = -e -c (cd /wrkdirs/usr/ports/print/texinfo/work/texinfo-6.5 && = _LATE_CONFIGURE_ARGS=3D"" ; if [ -z "" ] && ./configure --help=20 > 0 43375 43077 0 52 0 11164 2392 wait IJ 1 0:00.19 /bin/sh = ./configure --enable-nls --prefix=3D/usr/local --localstatedir=3D/var = --mandir=3D/usr/local/man --disable-silent-rules --infodir=3D/usr > 0 46850 43375 0 52 0 11164 2388 wait IJ 1 0:00.00 /bin/sh = ./configure --enable-nls --prefix=3D/usr/local --localstatedir=3D/var = --mandir=3D/usr/local/man --disable-silent-rules --infodir=3D/usr > 0 46857 46850 0 52 0 11080 2060 wait IJ 1 0:00.04 /bin/sh = ./configure --disable-option-checking --prefix=3D/usr/local --enable-nls = --localstatedir=3D/var --mandir=3D/usr/local/man --disable-s >=20 > 0 47796 46857 0 52 0 113840 26184 wait IJ 1 0:00.15 = /usr/local/bin/qemu-arm-static /usr/bin/cc -o conftest -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -mcpu=3Dcortex-a= >=20 > 0 47801 47796 0 52 0 285300 39672 uwait IJ 1 0:00.22 = qemu-arm-static -L /usr/gnemul/qemu-arm /usr/bin/ld --eh-frame-hdr = -dynamic-linker /libexec/ld-elf.so.1 --hash-style=3Dboth --enable-new- >=20 > So the "/usr/local/bin/qemu-arm-static /usr/bin/cc . . ." > creates the child "qemu-arm-static -L /usr/gnemul/qemu-arm /usr/bin/ld = . . ." > process and the two get hung up. Letting it sit for long periods does > not let it progress. >=20 > The full commands are (note the "-pipe" vs. the = "/tmp/conftest-6c0832.o"): >=20 > /usr/local/bin/qemu-arm-static /usr/bin/cc -o conftest -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG conftest.c >=20 > and: >=20 > qemu-arm-static -L /usr/gnemul/qemu-arm /usr/bin/ld --eh-frame-hdr = -dynamic-linker /libexec/ld-elf.so.1 --hash-style=3Dboth = --enable-new-dtags -o conftest /usr/lib/crt1.o /usr/lib/crti.o = /usr/lib/crtbegin.o -L/usr/lib /tmp/conftest-6c0832.o -lgcc --as-needed = -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed = /usr/lib/crtend.o /usr/lib/crtn.o >=20 > For reference for /tmp/conftest-6c0832.o : >=20 > # ls -lTd = /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/01/tmp/conftest-6c0= 832.o > -rw-r--r-- 1 root wheel 4204 Oct 26 17:33:13 2018 = /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/01/tmp/conftest-6c0= 832.o >=20 > (I'm not using tmpfs or the like at all.) >=20 >=20 > The context is based on head -r339076 an is on a > Ryzen Threadripper 1950X system, natively booted > (not Hyper-V). (I've not tried under Hyper-V yet.) >=20 > Note: I have built ports similarly before --but the > last time was back in March-May sometime. >=20 > # poudriere jail -jFBSDFSSDjailArmV7 -i > Jail name: FBSDFSSDjailArmV7 > Jail version: 12.0-ALPHA8 > Jail arch: arm.armv7 > Jail method: null > Jail mount: /usr/obj/DESTDIRs/clang-armv7-installworld-poud > Jail fs: =20 > Jail updated: 2018-10-26 16:42:55 > Tree name: default > Tree method: null > Status: parallel_build: > Building started: 2018-10-26 17:29:36 > Elapsed time: 02:47:50 > Packages built: 0 > Packages failed: 0 > Packages ignored: 0 > Packages skipped: 0 > Packages total: 84 > Packages left: 84 >=20 > # poudriere ports -l > PORTSTREE METHOD TIMESTAMP PATH > default null 2017-08-14 21:07:05 /usr/ports >=20 >=20 > I have yet to think of a way to look into this or to work around > it. But my long running build on an Orange Pi Plus 2nd Edition > has finished so I'll update from that for now. I tried again and when it hung up I used gdb to attach to the ld process and later to detach: # gdb `which qemu-arm-static` . . . (gdb) attach 18703 Attaching to program: /usr/local/bin/qemu-arm-static, process 18703 Couldn't get registers: Device busy. . . . (gdb) bt #0 _umtx_op () at _umtx_op.S:3 #1 0x0000000060050cd4 in _umtx_wait_uint_private (where=3D0x0, = addr=3D, target_val=3D, tsz=3D, t=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-495fb3a/b= sd-user/freebsd/os-thread.c:258 #2 freebsd_lock_umutex (target_addr=3D4102556064, id=3D100867, ts=3D0x0, = mode=3D) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-495fb3a/b= sd-user/freebsd/os-thread.c:890 #3 0x000000006004a808 in do_freebsd__umtx_op (obj=3D4102556064, = op=3D, val=3D0, uaddr=3D0, target_time=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-495fb3a/b= sd-user/freebsd/os-thread.h:359 #4 0x00000000600414d5 in do_freebsd_syscall (cpu_env=3D0x8607a4c58, = num=3D454, arg1=3D, arg2=3D, = arg3=3D, arg4=3D0, arg5=3D0, arg6=3D-185272152, arg7=3D0, = arg8=3D0) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-495fb3a/b= sd-user/syscall.c:1364 #5 0x0000000060038d03 in target_cpu_loop (env=3D0x8607a4c58) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-495fb3a/b= sd-user/arm/target_arch_cpu.h:207 #6 0x00000000600386a9 in cpu_loop (env=3D0xf48809bc) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-495fb3a/b= sd-user/main.c:121 #7 0x0000000060039922 in main (argc=3D-10608, argv=3D0x7fffffffd1d8) at = /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-495fb3a/b= sd-user/main.c:513 (gdb) detach Detaching from program: /usr/local/bin/qemu-arm-static, process 18703 Things started back up from there. We will see if it hangs up again. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Sat Oct 27 23:53:23 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD71F10D8AD8 for ; Sat, 27 Oct 2018 23:53:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-22.consmr.mail.gq1.yahoo.com (sonic312-22.consmr.mail.gq1.yahoo.com [98.137.69.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4338483035 for ; Sat, 27 Oct 2018 23:53:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Z7hhIFsVM1nCyDl0ZupAd9NoLHYkueSsCTBD0dOR8BeB7GxKVKVyr5dRBTUJwZM 3y3.QuQxUKRjcV2V6Niz2CqTIkl9ZPTpGlJb3lfnlZjrjKFf5BJm_5RZTpZIXkUsAltNz8Coy990 4XPVVGcnItgQJbEp7vMmMkgIDhhJSvC0fWNCgVayuqUCdyRBoKAmDDugGmJYapwvw5Mvm1DwkrS8 ljrFvqCS3KOwElgYe97ELvm77lFm7LgpLUz7MneW4StDmbI0OChBSonJ6hX5_6z9PZkGrvHB4URk 76DdWSHo7hvXu9.5XdA23r_dqzNUFR_NKQTDfBPz.GoBnE9evg_YjVzO8kSYVOeuxhskM7p01o5F 1CZsCgZDo_8TiB0ka1Lf1miYAYIICrmpgM7wCtD_dFtnJ_lrEOxq3XCFM1BzntjiKH7ctQUr8wqH 473tNtyvQ60XiajoRbsNzr_rNNXkt3qK.vQn9_c_1VnetRIIXTOhf8iYzGvhJ0qQE.850PDKMpn0 tYNxftekru4lQ7NsCYDWP0uTyT7zLP4.113VZiHket0kw9lmpT5tbRFDyZOXVIj8Hj9bsuTu3Y3S aeHLcdpkmSif_EcYcml06fdVJOka4zBEcTx9nVjtdH2Rcx5vIhX4MYffxK33xVTtFKykNwsc93et 519dxjW3G5N17.KZYuQYu4Fy_k2Pvfo9e8GTZnmjbTg1hJ8j.0F0Iwcqfh7w_L8sgY7oTC5Islcl 0Ik5ZYq7.u16kDLgzBjMmRB3w9WVf8QVNFjIQaZj5f00s2G2Ju10g0fRFGxz_.Bn5.jWIaKs.HqP 8nZrGCpxRkY7s_h1sgLVUDOk8MBbLc9hhNarRzpiAriKDnIwDr.GP6UH3InXUVdY5ko_iyByX2ho ozc.yqPj_Sgd0Ao7OFFkZ1GfYptio4qBVRToSS8zwvRmlru2QgjfsfSOo7cY0fGu8ijGXnR9VOvG w0cCSRFzU5Dg5viSua7leyzLkJKhBg87l9c9wFl2i2NhkQvPh4uUEazc9nzUDMUMlIGQhK1sD9hI TVvmoq7cTQrVrX6It8BRFuvyL6Md4j7JRM3jnXHeGE9eRAXeqTbrIbTY4Z9m7 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sat, 27 Oct 2018 23:53:22 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp426.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ee0cc28ffc4714a30c4886e4775cf224; Sat, 27 Oct 2018 23:33:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r339076 amd64 -> armv7 port cross build attempt with native tools involved: hangs between a cc (wait) and its child ld (uwait) From: Mark Millard In-Reply-To: Date: Sat, 27 Oct 2018 16:33:03 -0700 Cc: FreeBSD Toolchain , freeBSD , FreeBSD Ports ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <33C58480-1E76-4748-83B4-CB39FAD8584A@yahoo.com> To: =?utf-8?Q?Mika=C3=ABl_Urankar?= , Sean Bruno X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 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, 27 Oct 2018 23:53:24 -0000 [Some of this discussion occurred off list. The point here is not specific to the hang that I originally reported.] On 2018-Oct-27, at 3:03 PM, Mark Millard wrote: >=20 >> . . . >>=20 >>=20 >>> There are bugs in qemu that can cause such deadlock, you can try = these >>> 2 patches: >>> = https://github.com/MikaelUrankar/qemu-bsd-user/commit/9424a5ffde4de2768ab6= baa45fdbe0dbb56a7371 >>> = https://github.com/MikaelUrankar/qemu-bsd-user/commit/d6f65a7f07d280b6906d= 499d8e465d4d2026c52b >>=20 >> I'll try those later. Thanks. (I need to get back to sleep.) >>=20 >> It was interesting that attach/detach to the ld process >> caused it to progress. The rest of the build completed >> just fine. But that one spot consistently hung up before >> trying gdb to look at the back trace. >>=20 >=20 > Looking at the qemu code related to the 2nd patch: the > structure of the field copies (via __get_user) seems > very sensitive to the ABI rules for the target and > how things align and such, given that the structure > description and code are host code. __packed vs. not > is possibly not sufficient control to always make things > match right across all the potential combinations of > host and target from what I can see. >=20 > Lack of __packed may prove sufficient for my specific > context (amd64 host and armv7 target) but it seems > non-obvious what to do in general. >=20 > There would also seem to be big endian vs. little endian > issues on the individual __get_user styles of copies > when the host and target do not match for a multi-byte > numeric encoding. Well, I get the following for: #include "/usr/include/sys/event.h" // kevent #include // offsetof #include // printf int main() { printf("%lu\n", (unsigned long) sizeof(struct kevent)); printf("ident %lu\n", (unsigned long) offsetof(struct kevent, = ident)); printf("filter %lu\n", (unsigned long) offsetof(struct kevent, = filter)); printf("flags %lu\n", (unsigned long) offsetof(struct kevent, = flags)); printf("fflags %lu\n", (unsigned long) offsetof(struct kevent, = fflags)); printf("data %lu\n", (unsigned long) offsetof(struct kevent, = data)); printf("udata %lu\n", (unsigned long) offsetof(struct kevent, = udata)); printf("ext %lu\n", (unsigned long) offsetof(struct kevent, = ext)); return 0; } (This code avoided warnings for type mismatches with the printf strings and such.) amd64 native [host of qemu use] (comments hand added): # ./a.out 64 ident 0 filter 8 // NOTE! flags 10 // NOTE! fflags 12 // NOTE! data 16 udata 24 ext 32 (The above is not particularly important but I include it for completeness.) armv7 native [target in qemu use] (comments hand added): # ./a.out 64 // NOTE vs. below! ident 0 filter 4 // NOTE vs. above! flags 6 // NOTE vs. above! fflags 8 // NOTE vs. above! data 16 // NOTE vs. below! udata 24 // NOTE vs. below! ext 32 // NOTE vs. below! /usr/include/sys/event.h lacks __packed in both cases. With __packed in qemu-arm-static's source code for target_freebsd_kevent I confirm that via gdb for the qemu-arm-static: p/d sizeof(struct target_freebsd_kevent) p/d &((struct target_freebsd_kevent *)0)->ident p/d &((struct target_freebsd_kevent *)0)->filter p/d &((struct target_freebsd_kevent *)0)->flags p/d &((struct target_freebsd_kevent *)0)->fflags p/d &((struct target_freebsd_kevent *)0)->data p/d &((struct target_freebsd_kevent *)0)->udata p/d &((struct target_freebsd_kevent *)0)->ext reports as the 2nd patch's problem-report material reports (56,0,4,6,8,12,20,24): not even the right size. I also confirm that removing __packed in qemu's code and rebuilding and then checking with gdb reported a match to the above armv7 native report (64,0,4,6,8,16,24,32). I have not verified __packed used vs. not for any other combination of host and target platforms. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)