On 2016-Dec-2, at 12:12 AM, Mark Millard <markmi at dsl-only.net> wrote:
> [Reminder of my context: these amd64 efforts are really
> trying to make sure that I interpret powerpc family behavior
> correctly for C++ exception handling. Still it may be that
> there are other useful side-effects of my investigations.]
>
> On 2016-Dec-1, at 8:57 PM, Mark Millard <markmi at dsl-only.net> wrote:
>
>> Quick summaries from looking around at official amd64 builds
>> (via downloaded .iso's installed in VirtualBox under Mac OS X):
>>
>> _Unwind_RaiseException content (amd64 context only):
>>
>> RaiseExc. RaiseExc. RaiseException
>> dwarfdump save/rest. has "mov %rcx,%rsp"
>> r0?,r1? rdx? rax? return path?
>> --------- ---------- ------------------
>> release/9.3.0: r0,r1 rdx,rax mov %rcx,%rsp path
>> release/10.3.0: r0,r1 rdx,rax mov %rcx,%rsp path
>> stable/10 -r309258: r0,r1 rdx,rax mov %rcx,%rsp path
>> release/11.0.1: r0,r1 rdx,rax mov %rcx,%rsp path
>> stable/11 -r309280: r0,r1 rdx,rax mov %rcx,%rsp path
>> head (12) -r309302: <Niether> <Niether> <No>
I have confirmed that head being different above for amd64 is
because of the default WITH_LLVM_LIBUNWIND= and when built
using WITHOUT_LLVM_LIBUNWIND= head is like the others for the
above types of information.
I've added a note to my llvm report (26844) for powerpc64 and
powerpc indicating that all the specific material tied to
dwarf .eh information that I reported is for use of
WITHOUT_LLVM_LIBUNWIND= (for ppc and ppc64: the default for
both FreeBSD 11 and currently for head [12]).
I noted that comparing to WITH_LLVM_LIBUNWIND= dwarf information
was more complicated: one needs to know the expected differences
but I did not go into details.
> The following notes are not about the above differences
> in head vs. the others. I've not figured a good way to
> investigate the implications of head (12)'s differences
> above.
>
>> My simple example program's content compiled under the
>> host compiler:
>> ("clang++ -g -std=c++11 -pedantic -O2" when possible.)
>>
>> program uses pre _cxa_begin_catch compare and jump
>> _Unwind_Resume? logic?
>> --------------- -------------------------------------------
>> release/9.3.0: _Unwind_Resume sub $0x1,%rdx; je to _cxa_begin_catch
>> call
>> release/10.3.0: _Unwind_Resume cmp $0x1,%edx; jne skips _cxa_begin_catch
>> stable/10 -r309258: _Unwind_Resume cmp $0x1,%edx; jne skips _cxa_begin_catch
>> release/11.0.1: <No> <No test or jump>
>> stable/11 -r309280: <No> <No test or jump>
>> head (12) -r309302: _Unwind_Resume cmp $0x1,%edx; jne skips _cxa_begin_catch
These compiles have no clue if the eventual system was
built using WITHOUT_LLVM_LIBUNWIND= vs. WITH_LLVM_LIBUNWIND=
and so will persist independently.
> I explored more simple programs and. . .
>
> It looks like clang as it is in 11 treats:
>
> catch (std::<some-exception-type>& e) { . . . }
>
> as the last (or only) catch for a try as "catch
> everything" even for -O0 in the machine code,
> no separate _Unwind_Resume call for "no match".
>
> 11 depends on the other .eh information and its
> interpretation to avoid mis-delivery to the
> clause sequence for such a try.
>
> [The powerpc family may be similar. I need to
> avoid misreporting such differences from the
> general prior history to llvm as clang compiler
> problems.]
>
> [Back to amd64 land. . .]
> The other versions/configurations of clang and the
> g++ 4.2.1 compiler include the test and jump code
> to skip catches in sequence (including the last one
> in the try's source) and have use of _Unwind_Resume
> when the sequence does not have a match.
>
> So under 11.x older code's test and jump code might
> be redundant but is still apparently correct.
>
> It may be that such code is also redundant for head
> (12). But it appears that 12's machine code would
> then also have such redundant code as well.
>
> If there is some case where such code is not
> redundant for head (12) then 11's machine code
> might have problems under head in such cases.
> I do not know that any such case exists.
>
>
> I separately remind of the %rdx (64 bit) vs.
> %edx (32-bit) use in the test and jump code,
> 9.3.0 code being the odd code with %rdx in use
> that involves more bits.
>
>
> [Again: The above ignores the head (12)
> differences in libgcc_s.so.1 .eh dwarf
> information for _Unwind_RaiseException and
> the like and the library's noted machine
> code differences for _Unwind_RaiseException
> as well.]
===
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"
