public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/113566] New: btf: incorrect BTF_KIND_DATASEC entries for variables which are optimized out
@ 2024-01-23 19:47 david.faust at oracle dot com
2024-04-09 15:47 ` [Bug debug/113566] " cvs-commit at gcc dot gnu.org
0 siblings, 1 reply; 2+ messages in thread
From: david.faust at oracle dot com @ 2024-01-23 19:47 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug debug/113566] btf: incorrect BTF_KIND_DATASEC entries for variables which are optimized out
2024-01-23 19:47 [Bug debug/113566] New: btf: incorrect BTF_KIND_DATASEC entries for variables which are optimized out david.faust at oracle dot com
@ 2024-04-09 15:47 ` cvs-commit at gcc dot gnu.org
0 siblings, 0 replies; 2+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-04-09 15:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113566
--- Comment #1 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by David Faust <dfaust@gcc.gnu.org>:
https://gcc.gnu.org/g:8075477f81ae8d0abf64b80dfbd179151f91b417
commit r14-9876-g8075477f81ae8d0abf64b80dfbd179151f91b417
Author: David Faust <david.faust@oracle.com>
Date: Mon Apr 8 11:10:41 2024 -0700
btf: emit symbol refs in DATASEC entries only for BPF [PR114608]
The behavior introduced in
fa60ac54964 btf: Emit labels in DATASEC bts_offset entries.
is only fully correct when compiling for the BPF target with BPF CO-RE
enabled. In other cases, depending on optimizations, it can result in
an incorrect symbol reference in the entry bts_offset field for a symbol
which may not be emitted at all, causing link-time undefined symbol
reference errors like in PR114608.
The offending bts_offset field of BTF_KIND_DATASEC entries is in reality
only currently useful to consumers of BTF information for BPF programs
anyway. Correct the regression by only emitting symbol references in
these entries when compiling for the BPF target. For other targets, the
behavior returns to that prior to fa60ac54964.
The underlying cause is related to PR 113566 "btf: incorrect
BTF_KIND_DATASEC entries for variables which are optimized out." A
complete fix for 113566 is more involved and unsuitable for stage 4,
but will be addressed in the near future.
gcc/
PR debug/114608
* btfout.cc (btf_asm_datasec_entry): Only emit a symbol reference
when
generating BTF for BPF CO-RE target.
gcc/testsuite/
PR debug/114608
* gcc.dg/debug/btf/btf-datasec-1.c: Check bts_offset symbol
references
only for BPF target.
* gcc.dg/debug/btf/btf-datasec-2.c: Likewise.
* gcc.dg/debug/btf/btf-pr106773.c: Likewise.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2024-04-09 15:47 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-23 19:47 [Bug debug/113566] New: btf: incorrect BTF_KIND_DATASEC entries for variables which are optimized out david.faust at oracle dot com
2024-04-09 15:47 ` [Bug debug/113566] " cvs-commit at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).