Date: Fri, 6 Oct 2017 09:15:22 -0500 From: Justin Hibbits <jrh29@alumni.cwru.edu> To: Mark Millard <markmi@dsl-only.net> Cc: Warner Losh <imp@bsdimp.com>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: C++ in jemalloc Message-ID: <CAHSQbTB76OJYGtwzRRFfThJB5mYOKHi_BC9Eefc7Mn1A0-6sWg@mail.gmail.com> In-Reply-To: <BDC9F954-D0C5-4D7A-9CEA-D4FCA595B2FD@dsl-only.net> References: <BDC9F954-D0C5-4D7A-9CEA-D4FCA595B2FD@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Mark,
On Thu, Oct 5, 2017 at 11:58 PM, Mark Millard <markmi@dsl-only.net> wrote:
> Warner Losh imp at bsdimp.com wrote on
> Thu Oct 5 21:01:26 UTC 2017 :
>
>> Starting in FreeBSD 11, arm and powerpc are supported by clang,
>> but not super well. For FreeBSD 12, we're getting close for everything
>> except sparc64 (whose fate has not yet been finally decided).
>
> My understanding of the powerpc and powerpc64 status
> follows. This is based on my use of head via clang
> as much as I can for them.
>
> For TARGET_ARCH=powerpc64 and TARGET_ARCH=powerpc :
>
> lld is far from working last I knew. (I've focused
> more on the compilers for testing, using other
> linkers and such.) [lldb may be in a similar state
> for powerpc64. It does not build for powerpc.]
>
> clang 5 (and 4) generated code crashes on any thrown
> C++ exception. For example:
>
> #include <exception>
>
> int main(void)
> {
> try { throw std::exception(); }
> catch (std::exception& e) {}
> return 0;
> }
>
> crashes.
>
> Luckily most kernel and world code that I actively use
> does not throw C++ exceptions in my use.
Do you see this problem using libstdc++, et al, from base gcc 4.2.1?
Or using libc++?
I don't have the time right now to look into it, but if no one else is
able to in the next couple months I'll try to make the time when
higher priorities are done.
>
> But devel/kyua is majorly broken by the C++ exception
> issue: It makes extensive use of C++ exceptions. In my
> view that disqualifies clang as being "close": I view
> my activity as a hack until devel/kyua is generally
> operable and so available for use in testing.
>
> clang 5 currently can not build the TARGET_ARCH=powerpc
> kernel. (I was able to back in clang 4 days --but the
> resultant build failed to execute init fully after
> finishing the prior boot activity.) For the 32-bit
> context I use gcc 4.2.1 for building the kernel and
> clang 5 for building the world, system binutils
> in use in both cases.
What problem(s) do you see with this? If they're just compile time
failures they can be fixed pretty readily.
>
> I do build the kernel and world for
> TARGET_ARCH=powerpc64 via system clang 5. But I
> use ports binutils as well in order for this to
> finish and work overall.
>
>
> As for more modern devel/powerpc64-xtoolchain-gcc
> (so devel/powerpc64-gcc) versions being used to
> build the world and kernel for powerpc64 I've never
> been able to get lib32 on powerpc64 to work via
> such a build: it builds but fails to execute from
> dereferencing via an R30 that has an inappropriate
> value for the attempt ( lib32/crtbeginS.o code in
> _init in /usr/lib32/libc.so.* ). (The clang-based
> builds do not have this problem.) It has been a
> while since I've done devel/powerpc64-gcc
> experiments.
>
> I'm not aware of a devel/powerpc-xtoolchain-gcc
> as an alternative for 32-bit powerpc targeting.
There's documentation floating around (on the wiki maybe?) for doing
this. I won't check now, but it's not difficult (not trivial, but not
difficult). With the proposal to eliminate gcc 4.2.1 from our tree by
the end of the year, we need to get everything in place to make a
seamless transition, whether it be to external toolchain or to finish
up clang for powerpc. I really hope we can finish up clang. Please
continue to file bugs with as much detail as necessary to track down
and fix the problems--both in FreeBSD and upstream LLVM.
- Justin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHSQbTB76OJYGtwzRRFfThJB5mYOKHi_BC9Eefc7Mn1A0-6sWg>