Date: Fri, 12 Oct 2018 13:59:39 -0700 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, John Baldwin <jhb@freebsd.org> Subject: FYI: powerpc64 headbuilt via devel/powerpc64-xtoolchain-gcc and C++ exceptions for user code built by system-clang or devel/powerpc64-gcc (as of head -r339076 and ports -r480180) Message-ID: <E1167EAA-3F90-4F0A-9F51-53CFE1461617@yahoo.com>
next in thread | raw e-mail | index | archive | help
I built a powerpc64 head -r339076 via devel/powerpc64-gcc
and the like that built clang as cc as well (and
WITHOUT_LIB32). This included use of base/binutils to
the the powerpc64 set up. The system and kernel are
non-debug builds (but with symbols). [system-clang is not
used for buildworld buildkernel because of known
issues (last I tried).]
booting, buildworld, buildkernel, poudriere building
what totaled to be somewhat under 400 ports all seem
to work. But . . .
It been a long time since I've done something analogous
and a significant item in the result is different than in
the past once I started testing the throwing of C++
exceptions in code produced by system-clang or by
devel/powerpc64-gcc :
Such code ends up stuck using around 100% of a CPU.
An example is the program:
# more exception_test.cpp
#include <exception>
int main(void)
{
try { throw std::exception(); }
catch (std::exception& e) {}
return 0;
}
For system-clang it ended up with:
# ldd a.out
a.out:
libc++.so.1 => /usr/lib/libc++.so.1 (0x81006d000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x810184000)
libm.so.5 => /lib/libm.so.5 (0x8101ab000)
libc.so.7 => /lib/libc.so.7 (0x8101eb000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x810554000)
That program goes into an possibly unbounded execution.
(Historically when this program had problems it would
stop and produce a core file.)
When compiled by devel/powerpc64-gcc the a.out that results
does the same thing. ( /usr/local/bin/powerpc64-unknown-freebsd12.0-c++
as the compiler path ) So this is not really clang specific
in any way. This ended up with:
# ldd a.out
a.out:
libc++.so.1 => /usr/lib/libc++.so.1 (0x81006d000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x810184000)
libm.so.5 => /lib/libm.so.5 (0x8101ab000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8101eb000)
libc.so.7 => /lib/libc.so.7 (0x810211000)
(That should not have involved clang or llvm at all.)
But compiled by lang/gcc8's g++8 the a.out that results works
fine. This ends up with:
# ldd a.out
a.out:
libstdc++.so.6 => /usr/local/lib/gcc8/libstdc++.so.6 (0x81006e000)
libm.so.5 => /lib/libm.so.5 (0x8102c7000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x810307000)
libc.so.7 => /lib/libc.so.7 (0x81032d000)
It is not clear if using base/gcc as system cc
would do any better than using system-clang does
or than devel/powerpc64-gcc does: it is sort of
a variant of devel/powerpc64-gcc .
It will probably be some time before I figure out
much about what is going on.
Two things common to the problem cases are:
libc++.so.1 => /usr/lib/libc++.so.1 (0x81006d000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x810184000)
lang/gcc8 avoids those being involved.
Notes:
Some time ago I'd used system-clang to build such
programs in an environment built via devel/powerpc64-gcc
and devel/powerpc64-binutils and the programs worked.
The same for devel/powerpc64-gcc use: the code it
produced for the programs also worked. At this point
I've no clue what changed or when.
WITHOUT_LIB32= is because, for every post-gcc 4.2.1
that I've tried, the lib32 produced misuses R30 in
crtbeginS code (vs. the ABI for FreeBSD) and 32-bit
code just produces core files from the bad so-called
address dereference that results.
I'd rather have throwing C++ exceptions working and
lack of lib32 than have lib32 but not have throwing
C++ exceptions working. But at the moment how to have
such is not obvious when fairly modern compilers
and toolchains are involved.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1167EAA-3F90-4F0A-9F51-53CFE1461617>