https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113566
Bug ID: 113566
Summary: btf: incorrect BTF_KIND_DATASEC entries for variables
which are optimized out
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: btf-debug
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: david.faust at oracle dot com
CC: david.faust at oracle dot com, jemarch at gcc dot gnu.org
Target Milestone: ---
Target: all
Consider a simple program:
$ cat static.c
static int a = 5;
int foo (int x) {
return a + x;
}
When compiled with -O2, variable 'a' is optimized away, and its use is
replaced with a literal 5 in the resulting object code.
For all targets except BPF, BTF is emitted at early_finish always.
For the BPF target, if -mco-re is in effect, then BTF is emitted at finish
rather than early_finish.
The combination of -O2 with emitting BTF at early_finish causes incorrect
BTF_KIND_DATASEC entries to be emitted for all targets except BPF CO-RE:
$ ~/toolchains/bpf/bin/bpf-unknown-none-gcc -c -gbtf -O2 -mco-re static.c -o
static.o
$ /usr/sbin/bpftool btf dump file static.o
[1] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[2] FUNC_PROTO '(anon)' ret_type_id=1 vlen=1
'x' type_id=1
[3] VAR 'a' type_id=1, linkage=static
[4] FUNC 'foo' type_id=2 linkage=global
$ ~/toolchains/bpf/bin/bpf-unknown-none-gcc -c -gbtf -O2 -mno-co-re static.c -o
static.o
$ /usr/sbin/bpftool btf dump file static.o
[1] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[2] FUNC_PROTO '(anon)' ret_type_id=1 vlen=1
'x' type_id=1
[3] VAR 'a' type_id=1, linkage=static
[4] FUNC 'foo' type_id=2 linkage=global
[5] DATASEC '.data' size=0 vlen=1
type_id=3 offset=0 size=4 (VAR 'a')
(same for e.g. x86_64 with -gbtf)
In either case, 'a' is optimized away, and is not allocated in .data:
$ ~/toolchains/bpf/bin/bpf-unknown-none-objdump -dh static.o
static.o: file format elf64-bpfle
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000018 0000000000000000 0000000000000000 00000040 2**3
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00000000 0000000000000000 0000000000000000 00000058 2**0
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 0000000000000000 0000000000000000 00000058 2**0
ALLOC
...
So, the BTF_KIND_DATASEC entry claiming 'a' is allocated in .data is incorrect.
Clang correctly does not generate such a DATASEC entry.
The only case where the entry is correctly not generated by gcc is for the BPF
target with -mco-re, since in that case the DATASEC entries will be generated
at finish rather than early finish, by which time 'a' is known to be optimized
away.
