[PATCH,V2 0/3] Allow means for late BTF generation for BPF CO-RE

[Indu Bhagat <indu.bhagat@oracle.com>]

[Changes from V1]
- [1/3] bpf: Add new -mcore option for BPF CO-RE
  Moved the testcase from gcc.dg/debug/btf/ to gcc.target/bpf/. Adjusted the
  testcase a bit.
- targhooks: New target hook for CTF/BTF debug info emission
  (Same as V1)
- dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE usecase
  Moved the call to ctf_debug_finish (in dwarf2out_finish) before the point of
  early exit taken when dwarf_debuginfo_p () is false.
[End of Changes from V1]


Hello,

This patch series puts the framework in place for late BTF generation (in
dwarf2out_finish). This is needed for the landing of BPF CO-RE support in GCC,
patches for which were posted recently
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576719.html.

BPF's Compile Once - Run Everywhere (CO-RE) feature is used to make a compiled 
BPF program portable across kernel versions, all this without the need to
recompile the BPF program. A key part of BPF CO-RE capability is the BTF debug
info generated for them.

A traditional BPF program (non CO-RE) will have a .BTF section which contains
the type information in the BTF debug format. In case of CO-RE, however, an 
additional section .BTF.ext section is generated. The .BTF.ext section contains
the CO-RE relocations. A BPF loader will use the .BTF.ext section along with the
associated .BTF.ext section to adjust some references in the instructions of
program to ensure it is compatible with the required kernel version / headers.

Roughly, each CO-RE relocation record will contain the following info
 - offset of BPF instruction to be patched
 - the BTF ID of the data structure being accessed by the instruction, and 
 - an offset to the BTF string which encodes a series of field accesses to
   retrieve the field of interest in the instruction.

High-level design
-----------------
- The CTF container is populated with the compiler-internal representation for
the "type information" at dwarf2out_early_finish time.
- In case of CO-RE compilation, the information needed to generate .BTF.ext
section is added by the BPF backend to the CTF container (CTFC) at XXX time.
This introduces challenges in having LTO support for CO-RE - CO-RE relocations
can only be generated late, much like late DWARF. 
- Combining late and early BTF is not being done as the patch set disables LTO
to be used together with CO-RE for the BPF target.
- A new target hook is added for the CTFC (CTF Container) to know whether early
emission of CTF/BTF is allowed for the target.

Testing Notes
------------
- Bootstrapped and reg tested on x86_64
- make all-gcc for --target=bpf-unknown-none; tested ctf.exp, btf.exp and bpf.exp

Thanks,
Indu Bhagat (3):
  bpf: Add new -mcore option for BPF CO-RE
  targhooks: New target hook for CTF/BTF debug info emission
  dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE usecase

 gcc/config/bpf/bpf.c                      | 29 ++++++++++++++++
 gcc/config/bpf/bpf.opt                    |  4 +++
 gcc/doc/tm.texi                           |  6 ++++
 gcc/doc/tm.texi.in                        |  2 ++
 gcc/dwarf2ctf.c                           | 55 ++++++++++++++++++++++++-------
 gcc/dwarf2ctf.h                           |  4 ++-
 gcc/dwarf2out.c                           |  9 +++--
 gcc/target.def                            | 10 ++++++
 gcc/targhooks.c                           |  6 ++++
 gcc/targhooks.h                           |  2 ++
 gcc/testsuite/gcc.target/bpf/core-lto-1.c |  9 +++++
 11 files changed, 121 insertions(+), 15 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/bpf/core-lto-1.c

-- 
1.8.3.1