[Bug binutils/31561] New: AArch64 gas test case "SME extension (ZERO)" fails on s390x
https://sourceware.org/bugzilla/show_bug.cgi?id=31561
Bug ID: 31561
Summary: AArch64 gas test case "SME extension (ZERO)" fails on
s390x
Product: binutils
Version: 2.43 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: jremus at linux dot ibm.com
Target Milestone: ---
The AArch64 GNU Assembler test case "SME extension (ZERO)" fails in a GNU
Binutils build for target "aarch64-linux-gnu" on s390x as follows:
Target is aarch64-unknown-linux-gnu
Host is s390x-ibm-linux-gnu
...
../as-new -march=armv8-a+sme -o tmpdir/sme-4.o
/home/jremus/binutils/gas/testsuite/gas/aarch64/sme-4.s
Executing on host: sh -c {../as-new -march=armv8-a+sme -o tmpdir/sme-4.o
/home/jremus/binutils/gas/testsuite/gas/aarch64/sme-4.s 2>&1} /dev/null
dump.tmp (timeout = 300)
spawn [open ...]
/home/jremus/binutils/build-gcc-aarch64/gas/testsuite/../../binutils/objdump
-dr tmpdir/sme-4.o > tmpdir/dump.out
Executing on host: sh -c
{/home/jremus/binutils/build-gcc-aarch64/gas/testsuite/../../binutils/objdump
-dr tmpdir/sme-4.o > tmpdir/dump.out 2>dump.tmp} /dev/null (timeout = 300)
spawn [open ...]
regexp_diff match failure
regexp "^ 4: c00800ffzero{za}$"
line " 4: c00800ffzero{}"
regexp_diff match failure
regexp "^ 8: c00800ffzero{za}$"
line " 8: c00800ffzero{}"
regexp_diff match failure
regexp "^ c: c00800ffzero{za}$"
line " c: c00800ffzero{}"
regexp_diff match failure
regexp "^ 10: c00800ffzero{za}$"
line " 10: c00800ffzero{}"
regexp_diff match failure
regexp "^ 14: c00800ffzero{za}$"
line " 14: c00800ffzero{}"
regexp_diff match failure
regexp "^ 18: c0080001zero{za0\.d}$"
line " 18: c0080001zero{}"
regexp_diff match failure
regexp "^ 1c: c0080002zero{za1\.d}$"
line " 1c: c0080002zero{}"
regexp_diff match failure
regexp "^ 20: c0080004zero{za2\.d}$"
line " 20: c0080004zero{}"
regexp_diff match failure
regexp "^ 24: c0080008zero{za3\.d}$"
line " 24: c0080008zero{}"
regexp_diff match failure
regexp "^ 28: c0080010zero{za4\.d}$"
line " 28: c0080010zero{}"
regexp_diff match failure
regexp "^ 2c: c0080020zero{za5\.d}$"
line " 2c: c0080020zero{}"
regexp_diff match failure
regexp "^ 30: c0080040zero{za6\.d}$"
line " 30: c0080040zero{}"
regexp_diff match failure
regexp "^ 34: c0080080zero{za7\.d}$"
line " 34: c0080080zero{}"
regexp_diff match failure
regexp "^ 38: c0080001zero{za0\.d}$"
line " 38: c0080001zero{}"
regexp_diff match failure
regexp "^ 3c: c0080003zero{za0\.d, za1\.d}$"
line " 3c: c0080003zero{}"
regexp_diff match failure
regexp "^ 40: c0080007zero{za0\.d, za1\.d, za2\.d}$"
line " 40: c0080007zero{}"
regexp_diff match failure
regexp "^ 44: c008000fzero{za0\.d, za1\.d, za2\.d, za3\.d}$"
line " 44: c008000fzero{}"
regexp_diff match failure
regexp "^ 48: c008001fzero{za0\.s, za1\.d, za2\.d, za3\.d}$"
line " 48: c008001fzero{}"
regexp_diff match failure
regexp "^ 4c: c008003fzero{za0\.s, za1\.s, za2\.d, za3\.d}$"
line " 4c: c008003fzero{}"
regexp_diff match failure
regexp "^ 50: c008007fzero{za0\.h, za1\.s, za3\.d}$"
line " 50: c008007fzero{}"
regexp_diff match failure
regexp "^ 54: c00800ffzero{za}$"
line " 54: c00800ffzero{}"
regexp_diff match failure
regexp "^ 58: c0080080zero{za7\.d}$"
line " 58: c0080080zero{}"
regexp_diff match failure
regexp "^ 5c: c00800c0zero{za6\.d, za7\.d}$"
line " 5c: c00800c0zero{}"
regexp_diff match failure
regexp "^ 60: c00800e0zero{za5\.d, za6\.d, za7\.d}$"
line " 60: c00800e0zero{}"
regexp_diff match failure
regexp "^ 64: c00800f0zero{za4\.d, za5\.d, za6\.d, za7\.d}$"
line " 64: c00800f0zero
[Bug gas/31654] New: gas: Bad SFrame information when assembling with listing
https://sourceware.org/bugzilla/show_bug.cgi?id=31654 Bug ID: 31654 Summary: gas: Bad SFrame information when assembling with listing Product: binutils Version: 2.43 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: jremus at linux dot ibm.com Target Milestone: --- The assembler generates bad SFrame information when assembling the following CFI directive sequence with option "-Wa,-a" to generate a listing on a SFrame enabled target that uses FP and RA tracking: .cfi_offset , .cfi_offset , This causes multiple SFrame FREs for the same PC start address to be generated. The reason is that with listings enabled there is an additional DWARF DW_CFA_advance_loc CFI instruction with zero advance between both DW_CFA_offset instructions, that the DWARF .eh_frame generator is able to process correctly, but causes the .sframe generator to choke. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31654] gas: Bad SFrame information when assembling with listing
https://sourceware.org/bugzilla/show_bug.cgi?id=31654 Jens Remus changed: What|Removed |Added CC||indu.bhagat at oracle dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31654] gas: Bad SFrame information when assembling with listing
https://sourceware.org/bugzilla/show_bug.cgi?id=31654 --- Comment #1 from Jens Remus --- 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 FPRA sp+160u u 0006 sp+160c-72 c-48 0014 sp+160u u $ objdump --sframe test_fpra_with_alh.o ... Function Index : func idx [0]: pc = 0x0, size = 22 bytes STARTPC CFA FPRA sp+160u u 0006 sp+160u c-72 0006 sp+160c-72 c-48 0014 sp+160u c-72 0014 sp+160u 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.
[Bug binutils/31561] AArch64 gas test case "SME extension (ZERO)" fails on s390x
https://sourceware.org/bugzilla/show_bug.cgi?id=31561 Jens Remus changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jens Remus --- Commited fix approved by Nick to mainline. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31847] aarch64: bfd assert failure for discarded hidden symbol GOT reference
https://sourceware.org/bugzilla/show_bug.cgi?id=31847
Jens Remus changed:
What|Removed |Added
CC||jremus at linux dot ibm.com
--- Comment #1 from Jens Remus ---
On s390x we have a similar issue with superfluous dynamic NONE relocations that
I am looking into. I found a similar issue existed in x86-64 until commit
3747999c6bd4 ("ld: Extract _bfd_elf_link_iterate_on_relocs").
So far it looks like porting the x86-64 changes from the following commits
resolves the issue:
3747999c6bd4 ("ld: Extract _bfd_elf_link_iterate_on_relocs")
af969b14aedc ("PR 30569, always call elf_backend_size_dynamic_sections")
Effectively doing so also resolves an assertion hit when adapting your
"aarch64: Test DT_RELR with discarded sections" tests to s390x in the pic case
(without RELR, since we do not support that yet):
https://sourceware.org/pipermail/binutils/2024-June/134532.html
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/31919] New: AArch64 gas test case "gas/aarch64/brbe-brb-inst" fails on s390x
https://sourceware.org/bugzilla/show_bug.cgi?id=31919 Bug ID: 31919 Summary: AArch64 gas test case "gas/aarch64/brbe-brb-inst" fails on s390x Product: binutils Version: 2.43 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: jremus at linux dot ibm.com Target Milestone: --- The AArch64 GNU Assembler test case "gas/aarch64/brbe-brb-inst" fails in a GNU Binutils build for target "aarch64-linux-gnu" on s390x as follows: Target is aarch64-unknown-linux-gnu Host is s390x-ibm-linux-gnu ... regexp_diff match failure regexp "^.*:d509729ebrb iall// unpredictable encoding \(Rt!=31\): #30$" line " 4: d509729ebrb iall// unpredictable encoding (Rt!=31): #128849018880" regexp_diff match failure regexp "^.*:d50972bebrb inj // unpredictable encoding \(Rt!=31\): #30$" line " c: d50972bebrb inj // unpredictable encoding (Rt!=31): #128849018880" FAIL: gas/aarch64/brbe-brb-inst The AArch64 instruction table (aarch64-tbl.h) defines the operand Rt_IN_SYS_ALIASES as register number. During assembly it is correctly encoded as register number (reg.regno) in parse_operands. During disassembly it is first correctly decoded as register number (reg.regno) in aarch64_ext_regno called by aarch64_extract_operand, but then erroneously treated as immediate value (imm.value) in aarch64_print_operand. This resolves the assembler test case "gas/aarch64/brbe-brb-inst" to erroneously fail on s390. On AArch64 - being little-endian - the struct aarch64_opnd_info union fields reg.regno and imm.value share their least-significant bits. On s390 - being big-endian - they do not. I will send a patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31919] AArch64 gas test case "gas/aarch64/brbe-brb-inst" fails on s390x
https://sourceware.org/bugzilla/show_bug.cgi?id=31919 Jens Remus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jens Remus --- Commited fix approved by Alan to mainline. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31475] binutils: Support CREL relocation format
https://sourceware.org/bugzilla/show_bug.cgi?id=31475 Jens Remus changed: What|Removed |Added CC||jremus at linux dot ibm.com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32552] Potential access beyond size of generated .eh_frame sections for PLTs on x86
https://sourceware.org/bugzilla/show_bug.cgi?id=32552 Jens Remus changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||jbeulich at suse dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32552] New: Potential access beyond size of generated .eh_frame sections for PLTs on x86
https://sourceware.org/bugzilla/show_bug.cgi?id=32552 Bug ID: 32552 Summary: Potential access beyond size of generated .eh_frame sections for PLTs on x86 Product: binutils Version: 2.44 (HEAD) Status: UNCONFIRMED Severity: minor Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: jremus at linux dot ibm.com Target Milestone: --- Created attachment 15880 --> https://sourceware.org/bugzilla/attachment.cgi?id=15880&action=edit Patch that demonstrates the access beyond section size The .eh_frame sections for the PLT sections are generated by the linker as follows: 1. _bfd_x86_elf_late_size_sections sets the sections' initial sizes, allocates their contents buffers, initializes their contents (CIE and FDE) from a template, and fills in their FDE length field (PC Range). 2. _bfd_x86_elf_finish_dynamic_sections later fills in their FDE start field (PC Start). The size of the generated .eh_frame sections may change during linking: - The linker may add a padding to the last FDE of an .eh_frame section (e.g. in _bfd_elf_discard_section_eh_frame and bfd_elf_discard_info). - The linker may discard the FDE and even "minimize" the CIE (i.e. discard the initial Call Frame Instructions from the CIE while updating the CIE length field). The attached patch demonstrates that _bfd_x86_elf_finish_dynamic_sections sometimes accesses the generated .eh_frame section beyond its size when filling in the FDE start field. That is the added assertion fails for a bunch of ld tests, because the linker has discarded the FDE (and optionally "minimized" the CIE). How shall we deal with this? A) Add an .eh_frame section size test to the if-condition, so that the FDE start field is not filled in when the FDE got discarded. B) Test rawsize instead of size in the assertion (assuming rawsize corresponds to the contents buffer size). Note that rawsize sometimes is zero, although size is set and the contents buffer is initialized. Therefore rawsize would need to be initialized as well. C) Ignore and do not add any assertion(s), as the subject .eh_frame sections are linker generated and thus the contents buffer should always have enough room (assuming the linker never reallocates the contents buffer when discarding the FDE). I stumbled over this while porting the generation of .eh_frame for PLT from x86 to s390. Regards, Jens -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29655] s390x gas generates PC32DBL instead of PLT32DBL for function call
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #26 from Jens Remus ---
I took a stab at Andreas' GNU linker patch from comment #16. While it fixes
the issue demonstrated by Rui in comment #14 it causes some of the linker
shared and visibility tests to fail:
Running /home/jremus/binutils/ld/testsuite/ld-shared/shared.exp ...
FAIL: shared
...
Running /home/jremus/binutils/ld/testsuite/ld-vsb/vsb.exp ...
FAIL: visibility (hidden_normal)
FAIL: visibility (hidden_weak)
FAIL: visibility (protected)
FAIL: visibility (protected_undef_def)
FAIL: visibility (protected_weak)
FAIL: visibility (normal)
Note that those tests only fail on distributions that do not configure GCC with
--enable-default-pie. I have some patches in my queue to compile those and
others with $NOPIE_CFLAGS and link them with $NOPIE_LDFLAGS.
Further investigation shows the test failures are triggered by GCC 12-14
unconditionally emitting the larl address taking instruction with suffix @PLT
since since GCC commit 0990d93dd8a4 ("IBM Z: Use @PLT symbols for local
functions in 64-bit mode"). This would get resolved by Ilya's GCC patch
committed to mainline for GCC 15 with GCC commit a2e0a30c52fa ("IBM zSystems:
Do not use @PLT with larl").
To resolve this for GCC 12-14 I am working on a GNU linker patch to treat
PLT32DBL relocations for address taking instruction "larl rX,@PLT" as if
it was without @PLT and thus PC32DBL and require function pointer equality.
Early testing looks promising.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/32789] New: sframe: relocatable link of multiple text sections claims FDE to be sorted
https://sourceware.org/bugzilla/show_bug.cgi?id=32789
Bug ID: 32789
Summary: sframe: relocatable link of multiple text sections
claims FDE to be sorted
Product: binutils
Version: 2.45 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: jremus at linux dot ibm.com
Target Milestone: ---
When performing a relocatable link of multiple text sections of different name
(e.g. .text and .text.hot or when compiling with -ffunction-sections) the
resulting .sframe section claims its SFrame FDE to be sorted on PC. In general
I think this is wrong, as the ELF object file does not specify load addresses
or order of the individual .text.* sections. Note that it may be fine for the
Linux Kernel module loader use, if it loads the .text.* sections in the same
order they appear in the .ko.
Sample to demonstrate the issue:
#!/bin/bash
set -e -u -x
cat < sframe-foobar.c
void foo(void) {}
void bar(void) { foo(); }
EOF
gcc -fPIC -ffunction-sections -Wa,--gsframe -o sframe-foobar.o -c
sframe-foobar.c
ld -relocatable -o sframe-foobar-relocatable.o sframe-foobar.o
objdump -d --sframe sframe-foobar-relocatable.o
readelf -WSr --sframe sframe-foobar-relocatable.o
The resulting relocatable object looks as follows on s390x (minimized excerpt
of "readelf -WSr --sframe" output):
Section Headers:
[Nr] Name Address OffSize
[ 2] .text.foo 40 10
[ 3] .text.bar 50 20
[ 4] .rela.text.bar 0002c8 18
[ 7] .sframe d8 70
[ 8] .rela.sframe 000310 30
Relocation section '.rela.sframe' at offset 0x310 contains 2 entries:
OffsetTypeSymbol's Name + Addend
001c R_390_PC32 .text.foo + 1c
0030 R_390_PC32 .text.bar + 30
Contents of the SFrame section .sframe:
Header :
Version: SFRAME_VERSION_2
Flags: SFRAME_F_FDE_SORTED
Num FDEs: 2
Num FREs: 9
Function Index :
func idx [0]: pc = 0x0, size = 16 bytes
STARTPC CFA FPRA
sp+160u u
0004 sp+160r16 u*
0008 fp+160r16 u*
000e sp+160u u
func idx [1]: pc = 0x0, size = 32 bytes
STARTPC CFA FPRA
sp+160u u
0006 sp+160c-72 c-48
000c sp+320c-72 c-48
0010 fp+320c-72 c-48
001e sp+160u u
While the relocations in .rela.sframe would correctly update the FDE function
start address fields, loading .text.bar at a lower address than .text.foo would
invalidate the SFRAME_F_FDE_SORTED property.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/32789] sframe: relocatable link of multiple text sections claims FDE to be sorted
https://sourceware.org/bugzilla/show_bug.cgi?id=32789 Jens Remus changed: What|Removed |Added CC||indu.bhagat at oracle dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32789] sframe: relocatable link of multiple text sections claims FDE to be sorted
https://sourceware.org/bugzilla/show_bug.cgi?id=32789 --- Comment #1 from Jens Remus --- I missed to mention that this assumes linker mainline with Indu's "[RFC 0/4] Fix relocatable links with SFrame section" patch series on top: https://inbox.sourceware.org/binutils/20250308073853.78738-1-indu.bha...@oracle.com/ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32807] New: x86-68 test pr19636-3d is not run and would fail
https://sourceware.org/bugzilla/show_bug.cgi?id=32807
Bug ID: 32807
Summary: x86-68 test pr19636-3d is not run and would fail
Product: binutils
Version: 2.45 (HEAD)
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: jremus at linux dot ibm.com
Target Milestone: ---
While experimenting with porting x86-64 commit aec6b87e0b66 ("[x86] Resolve
non-PIC undefweak symbols in executable") to s390 I noticed that linker test
ld-x86-64/pr19636-3d.d was added but not listed in ld-x86-64/x86-64.exp with
subject commit. Git pickaxe does not report it ever been listed:
$ git log -S"pr19636-3d" -- ld/testsuite/ld-x86-64
Adding it to ld-x86-64/x86-64.exp as follow causes this test to fail in the
same way it would on s390:
diff --git a/ld/testsuite/ld-x86-64/x86-64.exp
b/ld/testsuite/ld-x86-64/x86-64.exp
--- a/ld/testsuite/ld-x86-64/x86-64.exp
+++ b/ld/testsuite/ld-x86-64/x86-64.exp
@@ -727,6 +727,7 @@ run_dump_test "pr19636-2m"
run_dump_test "pr19636-3a"
run_dump_test "pr19636-3b"
run_dump_test "pr19636-3c"
+run_dump_test "pr19636-3d"
run_dump_test "pr19645"
run_dump_test "pr19609-1a"
run_dump_test "pr19609-1b"
Excerpt from ld.log:
extra regexps in /home/jremus/git/binutils/ld/testsuite/ld-x86-64/pr19636-3d.d
starting with "^Symbol table '\.dynsym' contains [0-9]+ entries:$"
EOF from tmpdir/dump.out
FAIL: ld-x86-64/pr19636-3d
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/32807] x86-68 test pr19636-3d is not run and would fail
https://sourceware.org/bugzilla/show_bug.cgi?id=32807 Jens Remus changed: What|Removed |Added CC||hjl.tools at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32879] sframe: Assembler internal error when translating cfi_def_cfa_register
https://sourceware.org/bugzilla/show_bug.cgi?id=32879 Jens Remus changed: What|Removed |Added CC||jremus at linux dot ibm.com --- Comment #1 from Jens Remus --- >From a s390x perspective there are a few issues with the tentative patch: 1. On s390x the initial CFA offset at function entry is 160 instead of 0. Assuming a value of 0 is therefore wrong. 2. Using the register 6 as CFA base register in the test does not work for all architectures. At least on s390x this is none of SP and FP and therefore the test fails with: Warning: skipping SFrame FDE; non-SP/FP register 6 in .cfi_def_cfa_register A solution for the first issue may be to use the CFA offset of the current FRE, if there is no last FRE (= previous FRE?): > diff --git a/gas/gen-sframe.c b/gas/gen-sframe.c > @@ -1024,6 +1024,7 @@ sframe_xlate_do_def_cfa_register (struct > sframe_xlate_ctx *xlate_ctx, >struct sframe_row_entry *last_fre = xlate_ctx->last_fre; >/* Get the scratchpad FRE. This FRE will eventually get linked in. */ >struct sframe_row_entry *cur_fre = xlate_ctx->cur_fre; > + offsetT cfa_offset = 0; offsetT cfa_offset; > >gas_assert (cur_fre); >/* Define the current CFA rule to use the provided register (but to > @@ -1038,7 +1039,9 @@ sframe_xlate_do_def_cfa_register (struct > sframe_xlate_ctx *xlate_ctx, >return SFRAME_XLATE_ERR_NOTREPRESENTED; /* Not represented. */ > } >sframe_fre_set_cfa_base_reg (cur_fre, cfi_insn->u.r); > - sframe_fre_set_cfa_offset (cur_fre, last_fre->cfa_offset); > + if (last_fre) > +cfa_offset = last_fre->cfa_offset; else cfa_offset = cur_fre->cfa_offset; > + sframe_fre_set_cfa_offset (cur_fre, cfa_offset); >cur_fre->merge_candidate = false; > >return SFRAME_XLATE_OK; At least that causes the correct initial CFA offset of 160 to be picked up on s390x. But maybe cur_fre->merge_candidate needs to be factored in as well, if both last_fre and curr_fre exist? -- You are receiving this mail because: You are on the CC list for the bug.
