public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH,V3 0/3] Allow means for late BTF generation for BPF CO-RE
@ 2021-08-31 14:08 Indu Bhagat
  2021-08-31 14:08 ` [PATCH,V3 1/3] debug: add BTF_WITH_CORE_DEBUG debug format Indu Bhagat
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Indu Bhagat @ 2021-08-31 14:08 UTC (permalink / raw)
  To: gcc-patches

[Changes from V2]
- Instead of target hook, the patch set now adds a new debug format
BTF_WITH_CORE_DEBUG.
- Renamed the BPF option from -mcore to -mco-re.
- Adapted the commit logs a bit.
[End of Changes from V2]


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 earlier -
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 used.  The .BTF.ext section contains
the CO-RE relocations. A BPF loader will use the .BTF.ext section along with the
associated .BTF section to adjust some references in the instructions of BPF
program to ensure it is compatible with the required kernel version / headers.

A .BTF.ext section contains the CO-RE relocation records. 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 "access string" - a BTF string which encodes a series of 
   field accesses to retrieve the field of interest in the instruction.

The .BTF.ext section does not have a string table of its own, so these "access
strings" are placed in the .BTF section string table. The CO-RE relocation
records refer to them by offset into the .BTF string table.

Example of access string encoding:

 struct S {
     int a;
     union {
	 int _unused;
	 int b;
	 char c;
	 } u[4];
 };

struct S *foo = ...;
int x  = foo->a;          /* encoded as "0:0"     */
int y  = foo[4]->u[2].b   /* encoded as "4:1:2:1" */
char z = foo->u[3].c      /* encoded as "0:1:3:2" */

This means that writing out of a .BTF section needs to be delayed until after
these "access strings" have been added by the BPF backend, when CO-RE is in
effect.

High-level design
-----------------
- The CTF container (CTFC) is populated with the compiler-internal
representation for the "type information" at dwarf2out_early_finish time.  This
information is used for generation of the .BTF section.
- For CO-RE relocation records, the information needed to generate .BTF.ext
section is added by the BPF backend to the CTF container (CTFC) at expand time.
- A new debug format BTF_WITH_CORE_DEBUG is being added.
- The BPF backend updates the write_symbols variable with BTF_WITH_CORE_DEBUG
debug format signalling the rest of the compiler that BPF/CO-RE is in effect,
and hence the need to generate the BTF CO-RE relocation records.
- BTF debug information is emitted late in dwarf2out_finish when
BTF_WITH_CORE_DEBUG debug format is requested by the user (implicitly via the
command line option -mco-re for the BPF backend).
- Combining early BTF and late BTF/CO-RE debug information is not feasible due
to the way BTF CO-RE format is defined and lack of linker support for the BTF
debug format.
- Lastly, LTO is disallowed to be used together with CO-RE for the BPF 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):
  debug: add BTF_WITH_CORE_DEBUG debug format
  bpf: Add new -mco-re option for BPF CO-RE
  dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE usecase

 gcc/config/bpf/bpf.c                      | 25 ++++++++++++++
 gcc/config/bpf/bpf.opt                    |  4 +++
 gcc/dwarf2ctf.c                           | 54 +++++++++++++++++++++++--------
 gcc/dwarf2ctf.h                           |  4 ++-
 gcc/dwarf2out.c                           |  9 ++++--
 gcc/flag-types.h                          |  6 +++-
 gcc/flags.h                               |  4 +++
 gcc/opts.c                                |  8 +++++
 gcc/testsuite/gcc.target/bpf/core-lto-1.c |  9 ++++++
 9 files changed, 106 insertions(+), 17 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/bpf/core-lto-1.c

-- 
1.8.3.1


^ permalink raw reply	[flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-09-06  9:51 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-31 14:08 [PATCH,V3 0/3] Allow means for late BTF generation for BPF CO-RE Indu Bhagat
2021-08-31 14:08 ` [PATCH,V3 1/3] debug: add BTF_WITH_CORE_DEBUG debug format Indu Bhagat
2021-08-31 14:08 ` [PATCH,V3 2/3] bpf: Add new -mco-re option for BPF CO-RE Indu Bhagat
2021-08-31 14:08 ` [PATCH, V3 3/3] dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE usecase Indu Bhagat
2021-09-06  9:51 ` [PATCH,V3 0/3] Allow means for late BTF generation for BPF CO-RE Richard Biener

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).