[I've found the problem at the low level for
my context of using WITH_LIBCPLUSPLUS= with
the likes of devel/powerpc64-gcc but I do
not have a solution for WITH_LIBCPLUSPLUS=
so far. I give details of what I found.]
On 2018-Oct-14, at 12:40 AM, Mark Millard wrote:
> On 2018-Oct-12, at 1:59 PM, Mark Millard wrote:
>
>> 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
>>
>> 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:
>>
>> . . .
>>
>> 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.
>
> Here is what I've found so far.
>
> The code is looping in the following routine.
> (I've inserted 2 NOTE: lines for what the
> sustained looping is like.)
>
. . . (the routine was _Unwind_RaiseException) . . .
So far I've found that the following in
_Unwind_RaiseException stays invariant once
initialized --despite the uw_frame_state_for
and uw_update_context calls in
_Unwind_RaiseException 's loop that normally
update fs:
(gdb) print fs
$15 = {regs = {reg = {{loc = {reg = 0, offset = 0, exp = 0x0}, how =
REG_UNSAVED} , {loc = {reg = 18446744073709551608, offset =
-8,
exp = 0xfff8 }, how = REG_SAVED_OFFSET}, {loc = {reg = 0, offset = 0, exp =
0x0}, how = REG_UNSAVED} , {
loc = {reg = 16, offset = 16, exp = 0x10 }, how = REG_SAVED_OFFSET}, {loc = {reg = 0, offset = 0, exp =
0x0}, how = REG_UNSAVED} },
prev = 0x0}, cfa_offset = 0, cfa_reg = 1, cfa_exp = 0x0, cfa_how =
CFA_REG_OFFSET, pc = 0x8101999f8, personality = 0, data_align = -8, code_align
= 4, retaddr_column = 65,
fde_encoding = 27 '\033', lsda_encoding = 255 '?', saw_z = 1 '\001',
signal_frame = 0 '\0', eh_ptr = 0x0}
It turns out
