https://sourceware.org/bugzilla/show_bug.cgi?id=31654
--- Comment #1 from Jens Remus <jremus at linux dot ibm.com> --- Following is an example on s390x. Note that the following patch series are required for s390x: - sframe: Enhancements to SFrame info generation https://sourceware.org/pipermail/binutils/2024-April/133591.html - s390: Initial support to generate SFrame info from CFI directives in assembler https://sourceware.org/pipermail/binutils/2024-April/133597.html With patch "gas: Skip SFrame FDE if FP without RA on stack" from above series reverted: $ cat test_fpra_min.s .cfi_sections .sframe, .eh_frame .cfi_startproc stmg %r11,%r15,88(%r15) .cfi_rel_offset 11, 88 .cfi_rel_offset 14, 112 la %r11,0 la %r14,0 .Lreturn: lmg %r11,%r15,88(%r15) .cfi_restore 14 .cfi_restore 11 br %r14 .cfi_endproc $ as test_fpra_min.s -o test_fpra_without-alh.o $ as -Wa,-alh test_fpra_min.s -o test_fpra_with_alh.o $ ojbdump --sframe test_fpra_without-alh.o ... Function Index : func idx [0]: pc = 0x0, size = 22 bytes STARTPC CFA FP RA 0000000000000000 sp+160 u u 0000000000000006 sp+160 c-72 c-48 0000000000000014 sp+160 u u $ objdump --sframe test_fpra_with_alh.o ... Function Index : func idx [0]: pc = 0x0, size = 22 bytes STARTPC CFA FP RA 0000000000000000 sp+160 u u 0000000000000006 sp+160 u c-72 0000000000000006 sp+160 c-72 c-48 0000000000000014 sp+160 u c-72 0000000000000014 sp+160 u u Note that the FP-tracking information erroneously being displayed in the RA-tracking column, is why the patch "gas: Skip SFrame FDE if FP without RA on stack" got introduced. The outputs of "objdump -Wf" and "objdump -WF" are identical in both cases (with and without option "-alh"). Debugging of the SFrame processing of the DWARF CFI instructions shows that with option "-a" there are additional DW_CFA_advance_loc: DW_CFA_def_cfa: reg=15 offset=160 DW_CFA_advance_loc: lab1=L0, lab2=L0 DW_CFA_offset: reg=11 offset=-72 DW_CFA_advance_loc: lab1=L0, lab2=L0 <-- only with -a DW_CFA_offset: reg=14 offset=-48 DW_CFA_advance_loc: lab1=L0, lab2=L0 DW_CFA_restore: reg=14 DW_CFA_advance_loc: lab1=L0, lab2=L0 <-- only with -a DW_CFA_restore: reg=11 Debugging of the CFI directive processing in gas/dw2gencfi.c shows the following: - With option "-a" cfi_add_advance_loc() is invoked more often in dot_cfi() due to the condition (symbol_get_frag (frchain_now->frch_cfi_data->last_address) != frag_now) evaluating to true. - output_cfi_insn() of case DW_CFA_advance_loc enters the condition (symbol_get_frag (to) == symbol_get_frag (from)) without option "-a" and enters the else condition with option "-a". The else path has an interesting comment that suggests that there is logic to relax an advance by zero at a later stage: "... Call frag_grow with the sum of room needed by frag_more and frag_var to preallocate space ensuring that the DW_CFA_advance_loc4 is in the fixed part of the rs_cfa frag, so that the relax machinery can remove the advance_loc should it advance by zero." I don't have a clue how to resolve this potential issue in the SFrame generation. I could not figure out how to detect the advance of zero in the SFrame processing of DW_CFA_advance_loc, so that it could be treated special. -- You are receiving this mail because: You are on the CC list for the bug.