[llvm-bugs] [Bug 42790] New: [BPF] fix CO-RE incorrect index access string

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=42790

            Bug ID: 42790
           Summary: [BPF] fix CO-RE incorrect index access string
           Product: new-bugs
           Version: 9.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: ys114321 at gmail.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

Currently, we expect the CO-RE offset relocation records
a string encoding the original getelementptr access index,
so kernel bpf loader can decode it correctly.

For example,

struct s { int a; int b; };
struct t { int c; int d; };
#define _(x) (__builtin_preserve_access_index(x))
int get_value(const void *addr1, const void *addr2);
int test(struct s *arg1, struct t *arg2) {
  return get_value(_(&arg1->b), _(&arg2->d));
}

We expect two offset relocations:

reloc 1: type s, access index 0, 1
reloc 2: type t, access index 0, 1

Two globals are created to retain access indexes for the
above two relocations with global variable names.
The first global has a name "0:1:". Unfortunately,
the second global has the name "0:1:.1" as the llvm
internals automatically add suffix ".1" to a global
with the same name. Later on, the BPF peels the last
character and record "0:1" and "0:1:." in the
relocation table.

The kernel libbpf now has a checking to
enforce access string like "0:1" and the access string
like "0:1:." will result in rejection of the BTF.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190727/e9e8b662/attachment.html>