From owner-freebsd-toolchain@freebsd.org Sun Feb 21 11:52:50 2016 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 904DDAAF5E6 for ; Sun, 21 Feb 2016 11:52:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 555A01F4D for ; Sun, 21 Feb 2016 11:52:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5862 invoked from network); 21 Feb 2016 11:52:41 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 21 Feb 2016 11:52:41 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 21 Feb 2016 06:52:54 -0500 (EST) Received: (qmail 12166 invoked from network); 21 Feb 2016 11:52:54 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 21 Feb 2016 11:52:54 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3E1341C43AE; Sun, 21 Feb 2016 03:52:41 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc [fpr use also tested] From: Mark Millard In-Reply-To: <20160221090215.GA21511@vlakno.cz> Date: Sun, 21 Feb 2016 03:52:41 -0800 Cc: Dimitry Andric , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <1047AD1A-BCE1-44B0-A649-60343A89207D@dsl-only.net> References: <3A260EC5-E69A-4980-8F74-C04395F4E5F4@dsl-only.net> <20160215201800.GA20796@vlakno.cz> <74577A87-3006-43A9-9EAB-F51D946B6245@dsl-only.net> <28FF474D-2109-4605-8B2B-C5374CBCCF42@dsl-only.net> <8EB46124-3335-4643-8C64-16DA56D481F5@dsl-only.net> <8C40A5D7-C0B8-4142-89D4-228017C446CE@dsl-only.net> <20160220083450.GA55777@vlakno.cz> <68D66F67-EC4D-4CF2-A249-C7F0C4D4747D@FreeBSD.org> <20160221090215.GA21511@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 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, 21 Feb 2016 11:52:50 -0000 On 2016-Feb-21, at 1:02 AM, Roman Divacky = wrote: >=20 > On Sat, Feb 20, 2016 at 03:26:58PM +0100, Dimitry Andric wrote: >> On 20 Feb 2016, at 09:34, Roman Divacky = wrote: >>> Fwiw, I've just committed the patch to clang in r261422. You might = want >>> to keep using a local modification or ask dim@ to import that patch >>> to our copy of 3.8. >>=20 >> I've asked the LLVM release manager to consider merging this into the >> 3.8 branch. The fix looks trivial enough. :) >>=20 >> -Dimitry >>=20 >=20 > Cool :) >=20 > Mark, so what remains broken now beside the C++ exceptions? Also, can = you try > to take a look at kernel? >=20 > Thanks! Roman Implication of the below detailed answer: I've not thought about the = kernel much so far and it may well be some time before I do. Getting each thing fixed/operable/improved/worked-around for = world/userland has helped me explore finding the next thing. The C++ = exception problems currently block using "kyua -k /usr/tests/Kyuafile", = something I've been hoping to be able to do as evidence for how much is = (then) working based on a clang 3.8.0 buildworld. I've been sticking to = providing evidence for details world/userland issues before tackling = anything else. (So far I'm not generally fixing things, mostly just = finding evidence of problem details.) You may not know that I run PowerPC (32-bit) with modified signal = delivery: my adjustment uses a so-called "red-zone" to avoid the = incorrect timing of the stack pointer adjustments that clang 3.8.0's = code generation produces. (An ABI violation that I've worked around for = world/userland.) The work around was required to be able to have a = self-hosted buildworld's complete without make getting SEGV's/BusError's = that stop the build. No one is working on clang 3.8.0's 32-bit PowerPC stack-pointer-handling = ABI violations so far as I know. I doubt anyone will tackle the kernel overall for 32-bit PowerPC as long = as the stack pointer is decremented late and incremented early in = clang's generated code. I expect that handling such is comparatively = simple in world/userland (see above) compared to in the kernel and the = kernel's handling of is own stack. I doubt that FreeBSD would make even the red-zone code change for = world/userland official. It is operationally compatible with the = official ABI in world/userland but is temporarily somewhat wasteful of = some stack bytes. But mostly it is just something not required by the = official ABI and the signal delivery change does not help the = bigger/messier kernel-stack handling issue. I doubt FreeBSD would ever officially split buildworld and buildkernel = by using different compilers as I have, even temporarily. So no official = PowerPC clang context until everything works for both parts would be my = guess. I just view the split as a development/testing technique for = helping find details of problems in the simpler world/userland context = first. I did once take a quick look at clang 3.8.0 use in buildkernel instead = of using gcc 4.2.1. I do not remember all the details but one thing that = I remember is that clang's integrated-assembler notation and the = kernel's source files did not agree in various places. I have no formal descriptions of the two assembler notations or = description of how they correspond where different. This tends to = prevent any systematic process for such issues. (I'm no PowerPC = assembler expert: I look things up as I go.) If I remember the count right I also identified two other kernel = points-for-investigation very quickly and stopped there in order to = continue with world/userland investigations. I was guessing there was a = lot more to find relative to the kernel based on how quickly those 3 = subject areas were found. Since I started exploring FreeBSD I've observed that things happen = without prior notice that suspend my FreeBSD activity for weeks or = months at a time. That has happened several times. So I'm not sure how = far I'll get before such happens again. And PowerPC access has that issue even more: I can end up without access = to the old PowerMacs for long periods even if I can spend some time = exploring some (other) aspects of FreeBSD at the time. At this point I've no clue how I'll find what specific details are = involved in the "clang 3.8.0 compiled C++ exception infrastructure vs. = clang++380/g++5/g++49/g++421 compiled code" mismatch. I've no clue how = long that will take. So, overall, I'm not ready to think much about the kernel yet. =3D=3D=3D Mark Millard markmi at dsl-only.net