[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug ld/26378] New: [2.35 regression] incorrect WAX section flags in lin
From: |
nsz at gcc dot gnu.org |
Subject: |
[Bug ld/26378] New: [2.35 regression] incorrect WAX section flags in linker output |
Date: |
Wed, 12 Aug 2020 16:33:17 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=26378
Bug ID: 26378
Summary: [2.35 regression] incorrect WAX section flags in
linker output
Product: binutils
Version: 2.35
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
since binutils 2.35 i see WAX flags on some nobits sections:
$ cat a.s
.section .text.foo,"ax",@progbits
.global foo
.type foo,%function
foo:
ret
$ cat a.ld
SECTIONS {
.plt (NOLOAD) : { BYTE(0) }
.text.foo (NOLOAD) : { BYTE(0) }
}
$ as -c -o a.o a.s
$ ld -T a.ld a.o
$ readelf -SW a.out
There are 7 section headers, starting at offset 0x10b0:
Section Headers:
[Nr] Name Type Address Off Size ES Flg
Lk Inf Al
[ 0] NULL 0000000000000000 000000 000000 00
0 0 0
[ 1] .text.foo PROGBITS 0000000000000000 001000 000001 00 AX
0 0 1
[ 2] .plt NOBITS 0000000000000001 001001 000001 00 WAX
0 0 1
[ 3] .text.foo NOBITS 0000000000000002 001001 000001 00 WAX
0 0 1
[ 4] .symtab SYMTAB 0000000000000000 001008 000078 18
5 4 8
[ 5] .strtab STRTAB 0000000000000000 001080 000005 00
0 0 1
[ 6] .shstrtab STRTAB 0000000000000000 001085 00002a 00
0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
l (large), p (processor specific)
if i change '.text.foo' to '.test.foo' in a.s and a.ld
then there is no WAX on that section.
i don't see WAX prior to commit
commit 8c803a2dd7d3d742a3d0071914f557ef465afe71
Commit: Alan Modra <amodra@gmail.com>
CommitDate: 2020-03-02 11:36:19 +1030
elf_backend_section_flags and _bfd_elf_init_private_section_data
this affects linux kernel modules on aarch64, but the
behaviour change seems to be target independent.
before the commit above i see:
$ readelf -SW a.out
There are 7 section headers, starting at offset 0x10b0:
Section Headers:
[Nr] Name Type Address Off Size ES Flg
Lk Inf Al
[ 0] NULL 0000000000000000 000000 000000 00
0 0 0
[ 1] .text.foo PROGBITS 0000000000000000 001000 000001 00 AX
0 0 1
[ 2] .plt NOBITS 0000000000000001 001001 000001 00 WA
0 0 1
[ 3] .text.foo NOBITS 0000000000000002 001001 000001 00 WA
0 0 1
[ 4] .symtab SYMTAB 0000000000000000 001008 000078 18
5 4 8
[ 5] .strtab STRTAB 0000000000000000 001080 000005 00
0 0 1
[ 6] .shstrtab STRTAB 0000000000000000 001085 00002a 00
0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
l (large), p (processor specific)
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug ld/26378] New: [2.35 regression] incorrect WAX section flags in linker output,
nsz at gcc dot gnu.org <=
- [Bug ld/26378] [2.35 regression] incorrect WAX section flags in linker output, nsz at gcc dot gnu.org, 2020/08/12
- [Bug ld/26378] [2.35 regression] incorrect WAX section flags in linker output, hjl.tools at gmail dot com, 2020/08/12
- [Bug ld/26378] [2.35 regression] incorrect WAX section flags in linker output, hjl.tools at gmail dot com, 2020/08/12
- [Bug ld/26378] [2.35 regression] incorrect WAX section flags in linker output, hjl.tools at gmail dot com, 2020/08/12
- [Bug ld/26378] [2.35 regression] incorrect WAX section flags in linker output, hjl.tools at gmail dot com, 2020/08/12
- [Bug ld/26378] [2.35 regression] incorrect WAX section flags in linker output, amodra at gmail dot com, 2020/08/12
- [Bug ld/26378] [2.35 regression] incorrect WAX section flags in linker output, bero at lindev dot ch, 2020/08/13
- [Bug ld/26378] [2.35 regression] incorrect WAX section flags in linker output, toregionsfair at gmail dot com, 2020/08/16