Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Feb 2016 03:52:41 -0800
From:      Mark Millard <markmi@dsl-only.net>
To:        Roman Divacky <rdivacky@freebsd.org>
Cc:        Dimitry Andric <dim@FreeBSD.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Subject:   Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc [fpr use also tested]
Message-ID:  <1047AD1A-BCE1-44B0-A649-60343A89207D@dsl-only.net>
In-Reply-To: <20160221090215.GA21511@vlakno.cz>
References:  <3A260EC5-E69A-4980-8F74-C04395F4E5F4@dsl-only.net> <20160215201800.GA20796@vlakno.cz> <D702187C-6B8C-42AC-855D-45A570FDB0FA@dsl-only.net> <D3351840-02B5-4696-8163-D90A6E039E4C@dsl-only.net> <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>

next in thread | previous in thread | raw e-mail | index | archive | help

On 2016-Feb-21, at 1:02 AM, Roman Divacky <rdivacky at freebsd.org> =
wrote:
>=20
> On Sat, Feb 20, 2016 at 03:26:58PM +0100, Dimitry Andric wrote:
>> On 20 Feb 2016, at 09:34, Roman Divacky <rdivacky at vlakno.cz> =
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1047AD1A-BCE1-44B0-A649-60343A89207D>