在 2022/7/26 下午8:01, Xi Ruoyao 写道:
On Tue, 2022-07-26 at 19:42 +0800, Lulu Cheng wrote:
在 2022/7/26 下午5:44, Xi Ruoyao 写道:
Should we indicate that our .eh_frame section format has changed?
I don't really understand C++ exception handling, so: does the change
breaks something? For example, if foo links to libbar, libbar is built
with GCC 12 (or vice versa), would an exception thrown from libbar
properly caught by foo?
Generally changes.html is for compiler users (instead of developers),
and I believe at least 90% of users (including I) don't know the
potential consequences from a .eh_frame format change. So it's better
to describe the breakage and possible workaround here. If nothing will
be broken, we can just skip the change in changes.html.
The ASM_PREFERRED_EH_DATA_FORMAT macro before and after modification is
as follows:
#define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \
- (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_absptr)
+ (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel | DW_EH_PE_sdata4)
Use the following tests to describe the effect of modifying this macro
on the generated assembly code： #include <iostream> #include <exception>
using namespace std; int main() { try { throw 1; } catch
(int i) { cout << i << endl; } } The main comparisons
related to the eh_frame section are as follows： OLD NEW
.LFB1997 = . | .LFB1780 = . .cfi_startproc | .cfi_startproc
.cfi_personality 0x80,DW.ref.__gxx_personality_v0 | .cfi_personality
0x9b,DW.ref.__gxx_personality_v0 .cfi_lsda 0,.LLSDA1997 | .cfi_lsda
0x1b,.LLSDA1780 If the assembly file generated by the new gcc is
compiled with the binutils of version 2.38, the following error will be
reported: test.s:74: Error: invalid or unsupported encoding in
.cfi_personality test.s:75: Error: invalid or unsupported encoding in
.cfi_lsda
So I think I should judge whether binutils supports this encoding when
gcc is configured, and then choose how to define macro
ASM_PREFERRED_EH_DATA_FORMAT.
