Bugzilla Link	42790
Resolution	FIXED
Resolved on	Jul 29, 2019 01:59
Version	9.0
OS	Linux
Blocks	#41819
CC	@zmodem

Extended Description

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.