[PATCH] D83289: [BPF] Emit unknown types as byte arrays

Andrii Nakryiko via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 10 14:59:16 PDT 2020


anakryiko added a comment.

I concur with @yonghong-song, making float disappear is much bigger pain.

But I also think we should go with encoding and actually also fix encoding interpretation in kernel. Right now it allows only one of SIGNED, CHAR, or BOOL to be specified, which makes it impossible to correctly represent `signed char` type, as you can see from this:

  $ cat test.c
  struct s {
          signed char wat;
  };
  
  int main() {
          static struct s s = { .wat = -2 };
          return s.wat;
  }
  $ cc -g test.c -o test
  
  $ readelf -wi test | rg 'signed char'
      <48>   DW_AT_encoding    : 6        (signed char)
      <49>   DW_AT_name        : (indirect string, offset: 0x50): signed char
  
  $ pahole -JV test | rg 'signed char'
  [2] INT signed char size=1 bit_offset=0 nr_bits=8 encoding=(none)
  
  $ clang -g -target bpf -c test.c -o test.bpf.o
  
  $ bpftool btf dump file test.bpf.o | rg 'signed char'
  [5] INT 'signed char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED

DWARF gets it right. pahole does the same thing as for float, just emits no encoding. clang emits it as signed, but not a char.

BTW, I couldn't make neither pahole nor clang to emit CHAR encoding for anything (char, unsigned char, signed char), what was it supposed to be used for originally?

So I'd say let's add BTF_INT_FLOATING and fix SIGNED CHAR and CHAR problem altogether? Libbpf can trivially sanitize BTF for older kernels.

Thoughts?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83289/new/

https://reviews.llvm.org/D83289





More information about the llvm-commits mailing list