Mark Millard via freebsd-hackers
2018-10-17 20:25:39 UTC
[This summarizes other results without the code
and debugger evidence and such from my recent
explorations. It should be much easier to
follow than my exploration reports.]
Documents like DWARF5.pdf document the "row" vs. Location
information for Call Frame Information as (also used
for .eh_frame like materials for C++ exception handling):
(CFA: Cannonical Frame Address)
QUOTE ("Structure of Call Frame Information")
LOC CFA R0 R1...RN
L0
L1
...
LN
END QUOTE
Note that the CFA is conceptually one of the
registers in each row, even though it is not a
machine register but a way to calculate the
conceptual register's value from machine
registers.
The information for the machine registers are
typically based on the earlier CFA value (from
the same row!). Absent a correct CFA cell in
a row, most potential use of that row is likely
messed up.
One way CFA is found is by adding an offset to
the value of a machine register for the range
in question, Ln up to L(n+1) [or based on the
end of the overall range for the last Ln]. I
will use that for illustration because there
are examples of this in my testing.
/lib/libgcc_s.so.1 does not implement this
fully for some DW_CFA_* operations:
QUOTE (note the "every register" reference, so including CFA)
DW_CFA_remember_state
The DW_CFA_remember_state instruction takes no operands. The required action is to push the set of rules for every register onto an implicit stack.
DW_CFA_restore_state
The DW_CFA_restore_state instruction takes no operands. The required action is to pop the set of rules off the implicit stack and place them in the current row.
END QUOTE
In other words: push and pop a complete row,
not just machine registers information from
the row.
For example, the the "cfa_offset" for computing the CFA
value from from a register is not saved and restored.
Nor is which register the offset is based on. (This
can vary, though not in my examples.) In general the
CFA cell is not saved and restored, what ever its
contents.
So any compiler that produces code depending on
DW_CFA_remember_state and DW_CFA_restore_state
for .eh_frame like material ends up with C++
exception handling messed up when the
DW_CFA_restore_state should change the CFA to a
non-default one (from the prior
DW_CFA_remember_state).
This prevents reliable use of throwing C++ exceptions
when building via the likes of devel/powerpc64-gcc
or lang/gcc8 ( when not using
-Wl,-rpath=-Wl,-rpath=/usr/local/lib/gcc8 so that
/lib/libgcc_s.so.1 ends up being used). One result
can be _Unwind_RaiseException looping looking at
the same frame over and over instead of progressing
to the next frame. For example, this happens via
cfa_offset 0 being used. devel/powerpc64-gcc -O2
code tends to get that.
Notes:
For powerpc64, clang++ tends to use another register
(%r31) with the old value (of %r1, the stack pointer)
instead of involving the
DW_CFA_remember_state/DW_CFA_restore_state pair
based on just %r1. (clang has other problems
relative to sue for buildworld buildkernel.)
Code generation styles matter for if the incomplete
coverage by /lib/libgcc_s.so will be visible or not.
At this stage, WITH_LLVM_LIBUNWIND= builds
targeting powerpc64 do not even compile/assemble
the relevant code, apparently both because of
darwin specific assembler code and FreeBSD's build
not using the C-preprocessor on the .S file as
required. (There could be more to getting it
working.)
I do not know about other architecture/compiler
(or toolchain) combinations that may not yet be
able to use WITH_LLVM_LIBUNWIND= . But I'd
expect a potentially similar status from some.
A range of modern /usr/local/lib/gcc*/libgcc_s.so
do implement DW_CFA_remember_state/DW_CFA_restore_state
operations and they are put to use. So using the likes
of -Wl,-rpath=/usr/local/lib/gcc8 works for g++8 C++
exception handling (but is problematical for buildworld
buildkernel).
I made a similar exploration of the issue in around
early 2016 and got basically the same results, not that
I remembered much. But I now have a small source code
example that shows the cfa_offset issue for the likes
of devel/powerpc64-gcc output.
The standard source for throw_exception in
/lib/libgcc_s.so produces the cfa_offset problem
when devel/powerpc64-gcc is used to buildworld.
This turns all thrown C++ exceptions in to
unbounded looping in _Unwind_RaiseException for
that kind of context.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
and debugger evidence and such from my recent
explorations. It should be much easier to
follow than my exploration reports.]
Documents like DWARF5.pdf document the "row" vs. Location
information for Call Frame Information as (also used
for .eh_frame like materials for C++ exception handling):
(CFA: Cannonical Frame Address)
QUOTE ("Structure of Call Frame Information")
LOC CFA R0 R1...RN
L0
L1
...
LN
END QUOTE
Note that the CFA is conceptually one of the
registers in each row, even though it is not a
machine register but a way to calculate the
conceptual register's value from machine
registers.
The information for the machine registers are
typically based on the earlier CFA value (from
the same row!). Absent a correct CFA cell in
a row, most potential use of that row is likely
messed up.
One way CFA is found is by adding an offset to
the value of a machine register for the range
in question, Ln up to L(n+1) [or based on the
end of the overall range for the last Ln]. I
will use that for illustration because there
are examples of this in my testing.
/lib/libgcc_s.so.1 does not implement this
fully for some DW_CFA_* operations:
QUOTE (note the "every register" reference, so including CFA)
DW_CFA_remember_state
The DW_CFA_remember_state instruction takes no operands. The required action is to push the set of rules for every register onto an implicit stack.
DW_CFA_restore_state
The DW_CFA_restore_state instruction takes no operands. The required action is to pop the set of rules off the implicit stack and place them in the current row.
END QUOTE
In other words: push and pop a complete row,
not just machine registers information from
the row.
For example, the the "cfa_offset" for computing the CFA
value from from a register is not saved and restored.
Nor is which register the offset is based on. (This
can vary, though not in my examples.) In general the
CFA cell is not saved and restored, what ever its
contents.
So any compiler that produces code depending on
DW_CFA_remember_state and DW_CFA_restore_state
for .eh_frame like material ends up with C++
exception handling messed up when the
DW_CFA_restore_state should change the CFA to a
non-default one (from the prior
DW_CFA_remember_state).
This prevents reliable use of throwing C++ exceptions
when building via the likes of devel/powerpc64-gcc
or lang/gcc8 ( when not using
-Wl,-rpath=-Wl,-rpath=/usr/local/lib/gcc8 so that
/lib/libgcc_s.so.1 ends up being used). One result
can be _Unwind_RaiseException looping looking at
the same frame over and over instead of progressing
to the next frame. For example, this happens via
cfa_offset 0 being used. devel/powerpc64-gcc -O2
code tends to get that.
Notes:
For powerpc64, clang++ tends to use another register
(%r31) with the old value (of %r1, the stack pointer)
instead of involving the
DW_CFA_remember_state/DW_CFA_restore_state pair
based on just %r1. (clang has other problems
relative to sue for buildworld buildkernel.)
Code generation styles matter for if the incomplete
coverage by /lib/libgcc_s.so will be visible or not.
At this stage, WITH_LLVM_LIBUNWIND= builds
targeting powerpc64 do not even compile/assemble
the relevant code, apparently both because of
darwin specific assembler code and FreeBSD's build
not using the C-preprocessor on the .S file as
required. (There could be more to getting it
working.)
I do not know about other architecture/compiler
(or toolchain) combinations that may not yet be
able to use WITH_LLVM_LIBUNWIND= . But I'd
expect a potentially similar status from some.
A range of modern /usr/local/lib/gcc*/libgcc_s.so
do implement DW_CFA_remember_state/DW_CFA_restore_state
operations and they are put to use. So using the likes
of -Wl,-rpath=/usr/local/lib/gcc8 works for g++8 C++
exception handling (but is problematical for buildworld
buildkernel).
I made a similar exploration of the issue in around
early 2016 and got basically the same results, not that
I remembered much. But I now have a small source code
example that shows the cfa_offset issue for the likes
of devel/powerpc64-gcc output.
The standard source for throw_exception in
/lib/libgcc_s.so produces the cfa_offset problem
when devel/powerpc64-gcc is used to buildworld.
This turns all thrown C++ exceptions in to
unbounded looping in _Unwind_RaiseException for
that kind of context.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)