BPF List
 help / color / mirror / Atom feed
From: Yonghong Song <yhs@fb.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>,
	Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>,
	dwarves@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>, bpf <bpf@vger.kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH dwarves v2 2/2] btf_encoder: Normalize array index type for parallel dwarf loading case
Date: Tue, 17 May 2022 17:29:51 -0700	[thread overview]
Message-ID: <e2460561-79d0-3b08-1ecd-1876389d5c26@fb.com> (raw)
In-Reply-To: <YoPBxEscJTw2YPTC@kernel.org>



On 5/17/22 8:39 AM, Arnaldo Carvalho de Melo wrote:
> Em Thu, May 12, 2022 at 03:55:14PM -0700, Andrii Nakryiko escreveu:
>> On Wed, May 11, 2022 at 10:18 PM Yonghong Song <yhs@fb.com> wrote:
>>>
>>> With latest llvm15 built kernel (make -j LLVM=1), I hit the following
>>> error when build selftests (make -C tools/testing/selftests/bpf -j LLVM=1):
>>>    In file included from skeleton/pid_iter.bpf.c:3:
>>>    .../selftests/bpf/tools/build/bpftool/vmlinux.h:84050:9: error: unknown type name
>>>         '__builtin_va_list___2'; did you mean '__builtin_va_list'?
>>>    typedef __builtin_va_list___2 va_list___2;
>>>            ^~~~~~~~~~~~~~~~~~~~~
>>>            __builtin_va_list
>>>    note: '__builtin_va_list' declared here
>>>    In file included from skeleton/profiler.bpf.c:3:
>>>    .../selftests/bpf/tools/build/bpftool/vmlinux.h:84050:9: error: unknown type name
>>>         '__builtin_va_list__ _2'; did you mean '__builtin_va_list'?
>>>    typedef __builtin_va_list___2 va_list___2;
>>>            ^~~~~~~~~~~~~~~~~~~~~
>>>            __builtin_va_list
>>>    note: '__builtin_va_list' declared here
>>>
>>> The error can be easily explained with after-dedup vmlinux btf:
>>>    [21] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
>>>    [2300] STRUCT '__va_list_tag' size=24 vlen=4
>>>          'gp_offset' type_id=2 bits_offset=0
>>>          'fp_offset' type_id=2 bits_offset=32
>>>          'overflow_arg_area' type_id=32 bits_offset=64
>>>          'reg_save_area' type_id=32 bits_offset=128
>>>    [2308] TYPEDEF 'va_list' type_id=2309
>>>    [2309] TYPEDEF '__builtin_va_list' type_id=2310
>>>    [2310] ARRAY '(anon)' type_id=2300 index_type_id=21 nr_elems=1
>>>
>>>    [5289] PTR '(anon)' type_id=2308
>>>    [158520] STRUCT 'warn_args' size=32 vlen=2
>>>          'fmt' type_id=14 bits_offset=0
>>>          'args' type_id=2308 bits_offset=64
>>>    [27299] INT '__ARRAY_SIZE_TYPE__' size=4 bits_offset=0 nr_bits=32 encoding=(none)
>>>    [34590] TYPEDEF '__builtin_va_list' type_id=34591
>>>    [34591] ARRAY '(anon)' type_id=2300 index_type_id=27299 nr_elems=1
>>>
>>> Note that two array index_type_id's are different so the va_list and __builtin_va_list
>>> will have two versions in the BTF. With this, vmlinux.h contains the following code,
>>>    typedef __builtin_va_list va_list;
>>>    typedef __builtin_va_list___2 va_list___2;
>>> Since __builtin_va_list is a builtin type for the compiler,
>>> libbpf does not generate
>>>    typedef <...> __builtin_va_list
>>> and this caused __builtin_va_list___2 is not defined and hence compilation error.
>>> This happened when pahole is running with more than one jobs when parsing dwarf
>>> and generating btfs.
>>>
>>> Function btf_encoder__encode_cu() is used to do btf encoding for
>>> each cu. The function will try to find an "int" type for the cu
>>> if it is available, otherwise, it will create a special type
>>> with name __ARRAY_SIZE_TYPE__. For example,
>>>    file1: yes 'int' type
>>>    file2: no 'int' type
>>>
>>> In serial mode, file1 is processed first, followed by file2.
>>> both will have 'int' type as the array index type since file2
>>> will inherit the index type from file1.
>>>
>>> In parallel mode though, arrays in file1 will have index type 'int',
>>> and arrays in file2 wil have index type '__ARRAY_SIZE_TYPE__'.
>>> This will prevent some legitimate dedup and may have generated
>>> vmlinux.h having compilation error.
>>>
>>> This patch fixed the issue by creating an 'int' type as the
>>> array index type, so all array index type should be the same
>>> for all cu's even in parallel mode.
>>>
>>> Signed-off-by: Yonghong Song <yhs@fb.com>
>>> ---
>>>   btf_encoder.c | 3 ++-
>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>
>> LGTM, it should work reliably.
>>
>> Acked-by: Andrii Nakryiko <andrii@kernel.org>
> 
> Applied and testing.

Thanks!

> 
> - Arnaldo
>   
>>> Changelog:
>>>    v1 -> v2:
>>>     - change creation of array index type to be 'int' type,
>>>       the same as the type encoder tries to search in the current
>>>       types.
>>>
>>> diff --git a/btf_encoder.c b/btf_encoder.c
>>> index 1a42094..9e708e4 100644
>>> --- a/btf_encoder.c
>>> +++ b/btf_encoder.c
>>> @@ -1460,7 +1460,8 @@ int btf_encoder__encode_cu(struct btf_encoder *encoder, struct cu *cu)
>>>
>>>                  bt.name = 0;
>>>                  bt.bit_size = 32;
>>> -               btf_encoder__add_base_type(encoder, &bt, "__ARRAY_SIZE_TYPE__");
>>> +               bt.is_signed = true;
>>> +               btf_encoder__add_base_type(encoder, &bt, "int");
>>>                  encoder->has_index_type = true;
>>>          }
>>>
>>> --
>>> 2.30.2
>>>
> 

      reply	other threads:[~2022-05-18  0:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-12  5:17 [PATCH dwarves v2 1/2] libbpf: Sync with latest libbpf repo Yonghong Song
2022-05-12  5:18 ` [PATCH dwarves v2 2/2] btf_encoder: Normalize array index type for parallel dwarf loading case Yonghong Song
2022-05-12 22:55   ` Andrii Nakryiko
2022-05-17 15:39     ` Arnaldo Carvalho de Melo
2022-05-18  0:29       ` Yonghong Song [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e2460561-79d0-3b08-1ecd-1876389d5c26@fb.com \
    --to=yhs@fb.com \
    --cc=acme@kernel.org \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=arnaldo.melo@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=dwarves@vger.kernel.org \
    --cc=kernel-team@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox