Re: bpf_core_type_id_kernel with qualifier aborts clang compilation

[Yonghong Song <yhs@fb.com>]

On 3/4/21 8:41 AM, Yonghong Song wrote:
> 
> 
> On 3/4/21 3:25 AM, Lorenz Bauer wrote:
>> Hi Yonghong, Andrii,
>>
>> Some more poking at CO-RE. The code below leads to a compiler error:
>>
>> struct s {
>>      int _1;
>>      char _2;
>> };
>>
>> __section("socket_filter/type_ids") int type_ids() {
>>      return bpf_core_type_id_kernel(const struct s);
>> }
>>
>> Truncated output:
>> fatal error: error in backend: Empty type name for BTF_TYPE_ID_REMOTE 
>> reloc
>> PLEASE submit a bug report to 
>> https://bugs.llvm.org/   
>> and include the
>> crash backtrace, preprocessed source, and associated run script.
>> Stack dump:
>> 0.    Program arguments: clang-12 -target bpf -O2 -g -Wall -Werror
>> -mlittle-endian -c internal/btf/testdata/relocs.c -o
>> internal/btf/testdata/relocs-el.elf
>> 1.    <eof> parser at end of file
>> 2.    Per-function optimization
>> 3.    Running pass 'BPF Preserve Debuginfo Type' on function '@type_ids'
>> ...
>> clang: error: clang frontend command failed with exit code 70 (use -v
>> to see invocation)
>> Ubuntu clang version
>> 12.0.0-++20210126113614+510b3d4b3e02-1~exp1~20210126104320.178
>> Target: bpf
>>
>> "volatile" has the same problem. Interestingly, the same code works
>> for bpf_core_type_id_local. Is this expected?
> 
> First, bpf_core_type_id_local() works as compiler did not check type 
> name. for bpf_core_type_id_local(), there is no relocation, libbpf
> may need to adjust type id if it tries to do btf dedup, merging, etc.
> 
> Second, the above bpf_core_type_id_kernel() failed due to
> "const" (or "volatile") modifier. bpf_core_type_id_kernel()
> requires a type name as relocation will be performed.
> In the current implementation, the btf type is
>     const -> struct s
> and there is no name for "const", that is why compiler issues
> an explicit fatal error:
>      fatal error: error in backend: Empty type name for 
> BTF_TYPE_ID_REMOTE reloc
> 
> To fix the issue, just do not use any modifier,
>    bpf_core_type_id_kernel(struct s)
> should work fine.
> 
> I think in the case, it would be good if the compiler tries
> to peel off modifiers and find the ultimate type name
> instead of fatal error. I will put a patch on this.

Lorenz, the issue has been fixed by llvm patch
https://reviews.llvm.org/D97986. It is in llvm13 trunk now.
I have also requested the fix to backport to 12.0.1 release.
Thanks!

> 
> Thanks for reporting!
> 
>>
>> Best
>> Lorenz
>>