[Bug debug/113566] New: btf: incorrect BTF_KIND_DATASEC entries for variables which are optimized out

["david.faust at oracle dot com" <gcc-bugzilla@gcc.gnu.org>]

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.