Date: Fri, 2 Dec 2016 13:10:56 -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: <1016640A-6065-47A6-BF8C-F9DC2A38127A@dsl-only.net> In-Reply-To: <A44D5301-12A4-46FA-B9A0-A6BC4FF1EB8B@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> <A44D5301-12A4-46FA-B9A0-A6BC4FF1EB8B@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.]
>=20
> On 2016-Dec-1, at 8:57 PM, Mark Millard <markmi at dsl-only.net> =
wrote:
>=20
>> 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>
I have confirmed that head being different above for amd64 is
because of the default WITH_LLVM_LIBUNWIND=3D and when built
using WITHOUT_LLVM_LIBUNWIND=3D 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=3D (for ppc and ppc64: the default for
both FreeBSD 11 and currently for head [12]).
I noted that comparing to WITH_LLVM_LIBUNWIND=3D 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.
>=20
>> 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
These compiles have no clue if the eventual system was
built using WITHOUT_LLVM_LIBUNWIND=3D vs. WITH_LLVM_LIBUNWIND=3D
and so will persist independently.
> I explored more simple programs and. . .
>=20
> It looks like clang as it is in 11 treats:
>=20
> catch (std::<some-exception-type>& e) { . . . }
>=20
> 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".
>=20
> 11 depends on the other .eh information and its
> interpretation to avoid mis-delivery to the
> clause sequence for such a try.
>=20
> [The powerpc family may be similar. I need to
> avoid misreporting such differences from the
> general prior history to llvm as clang compiler
> problems.]
>=20
> [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.
>=20
> So under 11.x older code's test and jump code might
> be redundant but is still apparently correct.
>=20
> 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.
>=20
> 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.
>=20
>=20
> 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.
>=20
>=20
> [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?1016640A-6065-47A6-BF8C-F9DC2A38127A>