[Bug gas/31654] gas: Bad SFrame information when assembling with listing

[jremus at linux dot ibm.com]

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.