Date: Wed, 30 Nov 2016 18:03:32 -0800 From: Mark Millard <markmi@dsl-only.net> To: Ed Maste <emaste@freebsd.org> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, Dimitry Andric <dim@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: <81CBAB7A-B855-4673-B2E2-7862F441FDDA@dsl-only.net> In-Reply-To: <CAPyFy2ArXUYsyTC9LY_CqbU3FLVV0TeV%2BSandqd-SpPGMBL6Cg@mail.gmail.com> References: <750FCE4D-F25B-46E1-9383-B8A94AAA8792@dsl-only.net> <CAPyFy2ArXUYsyTC9LY_CqbU3FLVV0TeV%2BSandqd-SpPGMBL6Cg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-Nov-29, at 2:56 PM, Ed Maste <emaste at freebsd.org> wrote:
> On 29 November 2016 at 16:46, Mark Millard <markmi at dsl-only.net> wrote:
>>
>>
>> Summary: Does using clang 3.9.0 as the system compiler imply one should or
>> must (eventually?) use WITH_LLVM_LIBUNWIND to have C++ exceptions work?
>>
>> Do WITH_LLVM_LIBUNWIND and WITHOUT_LLVM_LIBUNWIND have the same criteria
>> for what dwarfdump should show for the exception information (if the
>> information to be shown is to be correct/sufficient for libunwind)?
>
> It does not. It should be possible to build a functional system both
> WITH_ and WITHOUT_LLVM_LIBUNWIND. The compiler is unaware of the
> _LLVM_LIBUNWIND setting. Both unwind libraries use the same unwind
> data.
Good to know. Thanks.
[As there are no clang-based powerpc64 linux builds to my knowledge
the following uses amd64/x86_64 examples instead for comparisons.]
What I see from "dwarfdump -v -v -F .../libgcc_s.so.1" for FreeBSD
head -r309179 vs. what I see for the clang 3.8.0 based OpenMandriva
Lx V3.0 leaves me a little worried: OpenMandriva Lx V3.0 is more
like what I would expect for:
_Unwind_RaiseException (9990 vs. c701)
_Unwind_ForcedUnwind (a330 vs. c857)
_Unwind_Resume (9fb0 vs. c927)
_Unwind_Resume_or_Rethrow (2da0 vs. c9e4)
(The numbers are just for my reference in finding the dwarfdump
material.)
By contrast FreeBSD has missing information from what I can tell.
For these 4 routines only: OpenMandriva Lx has scratch registers
listed (r0 and r1 from the set of normally volatile registers
normally not listed). No other routines in libgcc_s.so.1 have
this. FreeBSD has no such extra registers listed anywhere,
including not on the 4 where I'd expect them.
Using _Unwind_RaiseException as an example of those 4 routines
that I'm worried about. . .
[Notes: r7 is %rsp, r6 is %rbp, r3 is %rbx, r2 is %rcx, r1 is %rdx,
and r0 is %rax in amd64/x86_64 land. Only OpenMandriva Lx had
examples of the last two. I use the dwarfdump naming below.]
FreeBSD _Unwind_RaiseException:
fde section offset 5328 0x000014d0 cie offset for fde: 5332 0x000014d4
0 DW_CFA_advance_loc 1 (1 * 1)
1 DW_CFA_def_cfa_offset 16
3 DW_CFA_offset r6 -16 (2 * -8)
5 DW_CFA_advance_loc 3 (3 * 1)
6 DW_CFA_def_cfa_register r6
8 DW_CFA_advance_loc 16 (16 * 1)
9 DW_CFA_offset r3 -56 (7 * -8)
11 DW_CFA_offset r12 -48 (6 * -8)
13 DW_CFA_offset r13 -40 (5 * -8)
15 DW_CFA_offset r14 -32 (4 * -8)
17 DW_CFA_offset r15 -24 (3 * -8)
19 DW_CFA_nop
20 DW_CFA_nop
21 DW_CFA_nop
22 DW_CFA_nop
All the registers referenced are very common: lots of routines
having nothing to do with the Exception handling also list them.
OpenMandriva Lx _Unwind_RaiseException:
fde section offset 4280 0x000010b8 cie offset for fde: 4284 0x000010bc
0 DW_CFA_advance_loc 1 (1 * 1)
1 DW_CFA_def_cfa_offset 16
3 DW_CFA_offset r6 -16 (2 * -8)
5 DW_CFA_advance_loc 3 (3 * 1)
6 DW_CFA_def_cfa_register r6
8 DW_CFA_advance_loc 8 (8 * 1)
9 DW_CFA_offset r15 -24 (3 * -8)
11 DW_CFA_offset r14 -32 (4 * -8)
13 DW_CFA_offset r13 -40 (5 * -8)
15 DW_CFA_offset r12 -48 (6 * -8)
17 DW_CFA_advance_loc 20 (20 * 1)
18 DW_CFA_offset r3 -56 (7 * -8)
20 DW_CFA_offset r1 -64 (8 * -8)
22 DW_CFA_offset r0 -72 (9 * -8)
24 DW_CFA_advance_loc2 284
27 DW_CFA_remember_state
28 DW_CFA_restore r6
29 DW_CFA_def_cfa r2 8
32 DW_CFA_advance_loc 4 (4 * 1)
33 DW_CFA_restore_state
34 DW_CFA_advance_loc 21 (21 * 1)
35 DW_CFA_def_cfa r7 8
38 DW_CFA_nop
Note the lines for r1 and r0 that FreeBSD has no
equivalent of: These are the Exception ABI's
scratch registers usage that only apply to exception
handling code that uses certain built-ins that
imply the context. In normal routines r1 and r0 are
volatile and so are not listed on OpenMandriva Lx.
But FreeBSD never lists any scratch registers for the
exception handing ABI, unlike the Itanium's standard
that specified there are 4 --2 with predefined
purposes. (Itanimum used GP15-GP18 for the exception
handling scratch registers or something like that if
I remember right.)
So the amd64 FreeBSD information from clang 3.9.0 looks
wrong to me unless the Itanium's standard is not the
basis for what FreeBSD is doing here.
NOTE: Analogous incorrectness with observed scratch
register usage in builds based on clang 3.8.0 and
clang 3.9.0 for TARGET_ARCH=powerpc and
TARGET_ARCH=powerpc64 are part of what I've reported
as wrong to llvm for what blocks clang for them. In
this context actual crashes from asserts or SIGSEGV
during _Unwind_GetGR or _Unwind_SetGR for a scratch
register's index is what started my investigation of
the dwarfdump reports in the first place. I found
the register information missing in the dwarfdump
output and comments in the code about being such a
missing status for any GR leading to what I had
observed for references to that GR --and that is
my interpretation of the code so commented as well.
> Eventually new features may show up in Clang and LLVM's libunwind (and
> new versions of GNU's unwinder) that won't work with the old unwinder.
>
>> Your answer's detail might indicate that I've misdirected the llvm folks
>> in submittals like https://llvm.org/bugs/show_bug.cgi?id=26844 .
>>
>> There is also the question of if/when llvm's libunwind is ready to be used
>> for powerpc64 or powerpc (or . . .) if there are architecture specifics
>> involved. That answer might determine when C++ exceptions work (and so
>> when devel/kyua might have a chance to work) and is sort of separate from
>> the main question here but is still of interest overall.
>>
>> Should powerpc64 and powerpc clang 3.9.0 testing be using
>> WITH_LLVM_LIBUNWIND ? WITHOUT_LLVM_LIBUNWIND ? Both?
>
> For testing I think WITH_LLVM_LIBUNWIND is the interesting case. My
> eventual goal is to have a functioning Clang, LLD, LLDB, libunwind,
> and ELF Tool Chain on all of our supported architectures.
===
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?81CBAB7A-B855-4673-B2E2-7862F441FDDA>