https://sourceware.org/bugzilla/show_bug.cgi?id=33146
--- Comment #1 from Indu Bhagat <indu.bhagat at oracle dot com> ---
TL;DR: Some issue in the .gnu_object_only section which, IIUC, are generated
when there is (mixed) LTO and none-LTO usage with ld -r. Currently the .sframe
section in the .gnu_object_only contents show one 1 FDE when we expect 2 FDEs.
Using gdb with the LTO 4a linker command line:
gdb --args <test_path>/objdir/ld/tmpdir/ld/ld -v -plugin
/usr/libexec/gcc/x86_64-redhat-linux/13/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/13/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccYXTmaA.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o tmpdir/lto-4a.exe
/usr/lib/gcc/x86_64-redhat-linux/13/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-redhat-linux/13/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/13/crtbegin.o
-L<test_path>/install/x86_64-pc-linux-gnu/lib64 -L<test_path>/install/lib64
-L/usr/local/lib64 -L/lib64 -L/usr/lib64
-L<test_path>/install/x86_64-pc-linux-gnu/lib -L<test_path>/install/lib
-L/usr/local/lib -L/lib -L/usr/lib
-L<test_path>/binutils-gdb/ld/testsuite/ld-plugin
-L<test_path>/objdir/ld/tmpdir/ld -L/usr/lib/gcc/x86_64-redhat-linux/13
-L/usr/lib/gcc/x86_64-redhat-linux/13/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/13/../../..
--no-warn-execstack --no-error-execstack tmpdir/lto-4r-a.o tmpdir/dummy.o -lgcc
--push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed
-lgcc_s --pop-state /usr/lib/gcc/x86_64-redhat-linux/13/crtend.o
/usr/lib/gcc/x86_64-redhat-linux/13/../../../../lib64/crtn.o
123 BFD_ASSERT (cookie->rels + fde_count == cookie->relend);
(gdb) p fde_count
$3 = 1
(gdb) p sec->reloc_count
$4 = 2
(gdb) p *abfd
$5 = {filename = 0x77cb60 "/tmp/ccWuq930.obj-only.o", xvec = 0x6b5a80
<x86_64_elf64_vec>, iostream = 0x76dc20, iovec = 0x6d0360 <cache_iovec>,
lru_prev = 0x718c40, lru_next = 0x71ee00, where = 395, mtime = 0, id = 9,
flags = 32785, format = bfd_object, direction = read_direction,
The /tmp/ccWuq930.obj-only.o is the .gnu_object_only contents from the
tmpdir/lto-4r-a.o via cmdline_extract_object_only_section ().
Now, as for the generation of tmpdir/lto-4r-a.o, we see:
./ld-new -z norelro -z nomemory-seal
-L<test_path>/binutils-gdb/ld/testsuite/ld-plugin -r tmpdir/lto-4a.o
tmpdir/lto-4b.o tmpdir/lto-4c.o -o tmpdir/dump
mv tmpdir/dump tmpdir/lto-4r-a.o
So looking at .gnu_object_only in tmpdir/dump:
$ objcopy --dump-section .gnu_object_only=dump_gnu_object_only tmpdir/dump
$ readelf -r dump_gnu_object_only
Relocation section '.rela.text' at offset 0x378 contains 5 entries:
Offset Info Type Sym. Value Sym. Name +
Addend
000000000005 000e00000004 R_X86_64_PLT32 0000000000000020 bar - 4
00000000000a 00030000000a R_X86_64_32 0000000000000000 .rodata.str1.1 +
0
000000000013 000c00000004 R_X86_64_PLT32 0000000000000000 puts - 4
000000000021 00030000000a R_X86_64_32 0000000000000000 .rodata.str1.1 +
a
000000000026 000c00000004 R_X86_64_PLT32 0000000000000000 puts - 4
Relocation section '.rela.eh_frame' at offset 0x3f0 contains 2 entries:
Offset Info Type Sym. Value Sym. Name +
Addend
000000000020 000100000002 R_X86_64_PC32 0000000000000000 .text + 0
000000000050 000100000002 R_X86_64_PC32 0000000000000000 .text + 20
Relocation section '.rela.sframe' at offset 0x420 contains 2 entries:
Offset Info Type Sym. Value Sym. Name +
Addend
00000000001c 000100000002 R_X86_64_PC32 0000000000000000 .text + 0
00000000005c 000100000002 R_X86_64_PC32 0000000000000000 .text + 20
$ objdump -d dump_gnu_object_only
dump_gnu_object_only: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <foo>:
0: 48 83 ec 08 sub $0x8,%rsp
4: e8 00 00 00 00 call 9 <foo+0x9>
9: bf 00 00 00 00 mov $0x0,%edi
e: 48 83 c4 08 add $0x8,%rsp
12: e9 00 00 00 00 jmp 17 <foo+0x17>
17: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
1e: 00 00
0000000000000020 <bar>:
20: bf 00 00 00 00 mov $0x0,%edi
25: e9 00 00 00 00 jmp 2a <bar+0xa>
$ ../binutils/objdump --sframe dump_gnu_object_only
dump_gnu_object_only: file format elf64-x86-64
Contents of the SFrame section .sframe:
Header :
Version: SFRAME_VERSION_2
Flags: SFRAME_F_FDE_FUNC_START_PCREL
CFA fixed RA offset: -8
Num FDEs: 1
Num FREs: 3
Function Index :
func idx [0]: pc = 0x0, size = 23 bytes
STARTPC CFA FP RA
0000000000000000 sp+8 u f
0000000000000004 sp+16 u f
0000000000000012 sp+8 u f
The expected number of SFrame FDEs is 2.
--
You are receiving this mail because:
You are on the CC list for the bug.
