On 2016-Feb-21, at 1:02 AM, Roman Divacky <rdivacky at freebsd.org> wrote: > > 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. >> >> I've asked the LLVM release manager to consider merging this into the >> 3.8 branch. The fix looks trivial enough. :) >> >> -Dimitry >> > > Cool :) > > Mark, so what remains broken now beside the C++ exceptions? Also, can you try > to take a look at kernel? > > 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. === 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-unsubscr...@freebsd.org"
