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?

[Mark Millard]

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,raxmov %rcx,%rsp path
release/10.3.0: r0,r1 rdx,raxmov %rcx,%rsp path
stable/10 -r309258: r0,r1 rdx,raxmov %rcx,%rsp path
release/11.0.1: r0,r1 rdx,raxmov %rcx,%rsp path
stable/11 -r309280: r0,r1 rdx,raxmov %rcx,%rsp path
head (12) -r309302:

My simple example program's content compiled under the
host compiler:
("clang++ -g -std=c++11 -pedantic -O2" when possible.)

program usespre _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: 
stable/11 -r309280: 
head (12) -r309302: _Unwind_Resume  cmp $0x1,%edx; jne skips _cxa_begin_catch


===
Mark Millard
markmi at dsl-only.net

On 2016-Dec-1, at 2:39 AM, Mark Millard  wrote:

> [A top-post noting that it is head -r309179 that is different
> from 9.3-RELELASE for _Unwind_raiseException --and from
> stable/11 -r309125-- after noting my repeated "stable/11"
> references that should have said "head". Also for code
> that uses libgcc_s.so.1 for C++ exception handling the
> odd one is instead stable/11 that is not like the other
> two.]
> 
> First a correction to a systematic typing error:
> 
> -r309179 was correct but it is head, not stable/11 .
> 
> I repeat: My earlier comparison was between amd64
>  9.3-RELEASE and amd64 12-CURRENT -r309179 .
> 
> 
> What of stable/11 (by default WITHOUT_LLVM_LIBUNWIND= )
> vs. head (by default WITH_LLVM_LIBUNWIND= ) --and both
> of those vs. release/9.3.0 (implicitly
> WITHOUT_LLVM_LIBUNWIND= )?
> 
> First _Unwind_RaiseException as an example from
> inside libgc_s.so.1 for exception handling. . .
> 
> head -r309179 does *not* match stable/11 -r309125 or
> release/9.3.0 .
> 
> stable/11 -r309125 is more like release/9.3.0 .
> 
> So head *has* changed the amd64 C++ exception handling
> details as far as I can tell: WITH_LLVM_LIBUNWIND
> changes things.
> 
> A quick report below for stable/11 -r309125 shows
> it has both styles of returns, like release/9.3.0
> does. It has r0 and r1 saved and restored too.
> 
> stable/11 -r309125 _Unwind_RaiseException's code has:
> 
> 2cb0 <_Unwind_RaiseException> push   %rbp
> 2cb1 <_Unwind_RaiseException+0x1> mov%rsp,%rbp
> 2cb4 <_Unwind_RaiseException+0x4> push   %r15
> 2cb6 <_Unwind_RaiseException+0x6> push   %r14
> 2cb8 <_Unwind_RaiseException+0x8> push   %r13
> 2cba <_Unwind_RaiseException+0xa> push   %r12
> 2cbc <_Unwind_RaiseException+0xc> push   %rbx
> 2cbd <_Unwind_RaiseException+0xd> push   %rdx
> 2cbe <_Unwind_RaiseException+0xe> push   %rax
> 2cbf <_Unwind_RaiseException+0xf> sub$0x368,%rsp
> . . .
> [ the below is mostly like the 2nd 9.3 return path ]
> 2e2b <_Unwind_RaiseException+0x17b> lea0x8(%rbp,%rax,1),%rcx
> 2e30 <_Unwind_RaiseException+0x180> add$0x368,%rsp
> 2e37 <_Unwind_RaiseException+0x187> pop%rax
> 2e38 <_Unwind_RaiseException+0x188> pop%rdx
> 2e39 <_Unwind_RaiseException+0x189> pop%rbx
> 2e3a <_Unwind_RaiseException+0x18a> pop%r12
> 2e3c <_Unwind_RaiseException+0x18c> pop%r13
> 2e3e <_Unwind_RaiseException+0x18e> pop%r14
> 2e40 <_Unwind_RaiseException+0x190> pop%r15
> 2e42 <_Unwind_RaiseException+0x192> pop%rbp
> 2e43 <_Unwind_RaiseException+0x193> mov%rcx,%rsp
> 2e46 <_Unwind_RaiseException+0x196> retq   
> [ the above really does update %rsp twice during the return
>  sequence; the first of those updates is ineffective overall
>  and is from not having set optimization explicitly ]
> [ the below is much like the first 9.3 return path ]
> 2e4a <_Unwind_RaiseException+0x19a> add$0x368,%rsp
> 2e51 <_Unwind_RaiseException+0x1a1> pop%rax
> 2e52 <_Unwind_RaiseException+0x1a2> pop%rdx
> 2e53 <_Unwind_RaiseException+0x1a3> pop%rbx
> 2e54 <_Unwind_RaiseException+0x1a4> pop%r12
> 2e56 <_Unwind_RaiseException+0x1a6> pop%r13
> 2e58 <_Unwind_RaiseException+0x1a8> pop

[Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214863

--- Comment #9 from Baptiste Daroussin  ---
well this is a bug :)

They should not

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

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?

[Mark Millard]

[A top-post noting that it is head -r309179 that is different
from 9.3-RELELASE for _Unwind_raiseException --and from
stable/11 -r309125-- after noting my repeated "stable/11"
references that should have said "head". Also for code
that uses libgcc_s.so.1 for C++ exception handling the
odd one is instead stable/11 that is not like the other
two.]

First a correction to a systematic typing error:

-r309179 was correct but it is head, not stable/11 .

I repeat: My earlier comparison was between amd64
  9.3-RELEASE and amd64 12-CURRENT -r309179 .


What of stable/11 (by default WITHOUT_LLVM_LIBUNWIND= )
vs. head (by default WITH_LLVM_LIBUNWIND= ) --and both
of those vs. release/9.3.0 (implicitly
WITHOUT_LLVM_LIBUNWIND= )?

First _Unwind_RaiseException as an example from
inside libgc_s.so.1 for exception handling. . .

head -r309179 does *not* match stable/11 -r309125 or
release/9.3.0 .

stable/11 -r309125 is more like release/9.3.0 .

So head *has* changed the amd64 C++ exception handling
details as far as I can tell: WITH_LLVM_LIBUNWIND
changes things.

A quick report below for stable/11 -r309125 shows
it has both styles of returns, like release/9.3.0
does. It has r0 and r1 saved and restored too.

stable/11 -r309125 _Unwind_RaiseException's code has:

2cb0 <_Unwind_RaiseException> push   %rbp
2cb1 <_Unwind_RaiseException+0x1> mov%rsp,%rbp
2cb4 <_Unwind_RaiseException+0x4> push   %r15
2cb6 <_Unwind_RaiseException+0x6> push   %r14
2cb8 <_Unwind_RaiseException+0x8> push   %r13
2cba <_Unwind_RaiseException+0xa> push   %r12
2cbc <_Unwind_RaiseException+0xc> push   %rbx
2cbd <_Unwind_RaiseException+0xd> push   %rdx
2cbe <_Unwind_RaiseException+0xe> push   %rax
2cbf <_Unwind_RaiseException+0xf> sub$0x368,%rsp
. . .
[ the below is mostly like the 2nd 9.3 return path ]
2e2b <_Unwind_RaiseException+0x17b> lea0x8(%rbp,%rax,1),%rcx
2e30 <_Unwind_RaiseException+0x180> add$0x368,%rsp
2e37 <_Unwind_RaiseException+0x187> pop%rax
2e38 <_Unwind_RaiseException+0x188> pop%rdx
2e39 <_Unwind_RaiseException+0x189> pop%rbx
2e3a <_Unwind_RaiseException+0x18a> pop%r12
2e3c <_Unwind_RaiseException+0x18c> pop%r13
2e3e <_Unwind_RaiseException+0x18e> pop%r14
2e40 <_Unwind_RaiseException+0x190> pop%r15
2e42 <_Unwind_RaiseException+0x192> pop%rbp
2e43 <_Unwind_RaiseException+0x193> mov%rcx,%rsp
2e46 <_Unwind_RaiseException+0x196> retq   
[ the above really does update %rsp twice during the return
  sequence; the first of those updates is ineffective overall
  and is from not having set optimization explicitly ]
[ the below is much like the first 9.3 return path ]
2e4a <_Unwind_RaiseException+0x19a> add$0x368,%rsp
2e51 <_Unwind_RaiseException+0x1a1> pop%rax
2e52 <_Unwind_RaiseException+0x1a2> pop%rdx
2e53 <_Unwind_RaiseException+0x1a3> pop%rbx
2e54 <_Unwind_RaiseException+0x1a4> pop%r12
2e56 <_Unwind_RaiseException+0x1a6> pop%r13
2e58 <_Unwind_RaiseException+0x1a8> pop%r14
2e5a <_Unwind_RaiseException+0x1aa> pop%r15
2e5c <_Unwind_RaiseException+0x1ac> pop%rbp
2e5d <_Unwind_RaiseException+0x1ad> retq   

[Because of code order differences the above shows somewhat
more than I did for 9.3 .]

stable/11 -r309125 _Unwind_RaiseException's dwarfdump shows:

fde section offset 720 0x02d0 cie offset for fde: 724 0x02d4
 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 18  (18 * 1)
 9 DW_CFA_offset r0 -72  (9 * -8)
11 DW_CFA_offset r1 -64  (8 * -8)
13 DW_CFA_offset r3 -56  (7 * -8)
15 DW_CFA_offset r12 -48  (6 * -8)
17 DW_CFA_offset r13 -40  (5 * -8)
19 DW_CFA_offset r14 -32  (4 * -8)
21 DW_CFA_offset r15 -24  (3 * -8)

Note the r0 and r1 (and %rax and %rdx in the code)
so it is like release/9.3.0 in that respect.


(I've still not looked at 10.x and with 11 being as it
is I might not bother.)



What about programs that use libgcc_s.so.1 ? . . .

Looking at an example program shows a code interface
difference visible in that code. Look just before the
__cxa_begin_catch@plt call in head vs. stable/11:
head -r309179 has conditional code that stable/11
-r309125 does not:

00400caf  cmp$0x1,%edx
00400cb2  jne00400cf3 

(This has -O2 in use for both contexts.)

head -r309179 has that conditional code:

00400c90  push   %rbp
00400c91  mov%rsp,%rbp