Date: Fri, 2 Dec 2016 00:12:31 -0800 From: Mark Millard <markmi@dsl-only.net> To: Ed Maste <emaste@freebsd.org> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, Dimitry Andric <dim@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: WITH_LLVM_LIBUNWIND vs. WITHOUT_LLVM_LIBUNWIND, clang vs. gcc (such as devel/powerpc64-xtoolchain-gcc ): What is intended to be required for C++ exceptions to work? Message-ID: <A44D5301-12A4-46FA-B9A0-A6BC4FF1EB8B@dsl-only.net> In-Reply-To: <BB2D1D3F-8B3F-4F2F-A431-A65E86C30516@dsl-only.net> References: <750FCE4D-F25B-46E1-9383-B8A94AAA8792@dsl-only.net> <CAPyFy2ArXUYsyTC9LY_CqbU3FLVV0TeV%2BSandqd-SpPGMBL6Cg@mail.gmail.com> <81CBAB7A-B855-4673-B2E2-7862F441FDDA@dsl-only.net> <68972A8F-C8D4-4FF2-A933-ACCC79C15065@dsl-only.net> <8BA319C6-FAD1-445F-85C1-5086B5AA59A8@dsl-only.net> <BB2D1D3F-8B3F-4F2F-A431-A65E86C30516@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[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):
>=20
> _Unwind_RaiseException content (amd64 context only):
>=20
> 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>
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=3Dc++11 -pedantic -O2" when possible.)
>=20
> 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
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.=20
%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.]
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A44D5301-12A4-46FA-B9A0-A6BC4FF1EB8B>