[all-commits] [llvm/llvm-project] 0e347c: BPF: generate .rodata BTF datasec for certain init...

yonghong-song via All-commits all-commits at lists.llvm.org
Fri Jul 17 09:46:25 PDT 2020


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 0e347c0ff0a88a8412299d024c2f32201fe342d1
      https://github.com/llvm/llvm-project/commit/0e347c0ff0a88a8412299d024c2f32201fe342d1
  Author: Yonghong Song <yhs at fb.com>
  Date:   2020-07-17 (Fri, 17 Jul 2020)

  Changed paths:
    M llvm/lib/Target/BPF/BTFDebug.cpp
    A llvm/test/CodeGen/BPF/BTF/local-var-readonly-1.ll
    A llvm/test/CodeGen/BPF/BTF/local-var-readonly-2.ll

  Log Message:
  -----------
  BPF: generate .rodata BTF datasec for certain initialized local var's

Currently, BTF datasec type for .rodata is generated only if there are
user-defined readonly global variables which have debuginfo generated.

Certain readonly global variables may be generated from initialized
local variables. For example,
  void foo(const void *);
  int test() {
    const struct {
      unsigned a[4];
      char b;
    } val = { .a = {2, 3, 4, 5}, .b = 6 };
    foo(&val);
    return 0;
  }

The clang will create a private linkage const global to store
the initialized value:
  @__const.test.val = private unnamed_addr constant %struct.anon
      { [4 x i32] [i32 2, i32 3, i32 4, i32 5], i8 6 }, align 4

This global variable eventually is put in .rodata ELF section.

If there is .rodata ELF section, libbpf expects a BTF .rodata
datasec as well even though it may be empty meaning there are no
global readonly variables with proper debuginfo. Martin reported
a bug where without this empty BTF .rodata datasec, the bpftool
gen will exit with an error.

This patch fixed the issue by generating .rodata BTF datasec
if there exists local var intial data which will result in
.rodata ELF section.

Differential Revision: https://reviews.llvm.org/D84002




More information about the All-commits mailing list