On 01/05/2024 21:39, Eduard Zingerman wrote:
> On Wed, 2024-04-24 at 16:48 +0100, Alan Maguire wrote:
>
> [...]
>
>> @@ -532,11 +533,26 @@ static int symbols_resolve(struct object *obj)
>> __u32 nr_types;
>>
>> if (obj->base_btf_path) {
>> - base_btf = btf__parse(obj->base_btf_path, NULL);
>> + LIBBPF_OPTS(btf_parse_opts, optp);
>> + const char *path;
>> +
>> + if (obj->base) {
>> + optp.btf_sec = BTF_BASE_ELF_SEC;
>> + path = obj->path;
>> + base_btf = btf__parse_opts(path, &optp);
>> + /* fall back to normal base parsing if no BTF_BASE_ELF_SEC */
>> + if (libbpf_get_error(base_btf))
>> + base_btf = NULL;
>
> Should this be a fatal error?
> Since user requested '-B' explicitly?
>
No, the fallback behaviour is intended. The reason is this; if the user
is using an older pahole that does not support the generation of
distilled base BTF, there will be no .BTF.base section in modules. We
will however have specified the -B option, so we want to fall back to
normal resolve_btfids behaviour for modules. This avoids the need to
check if the BTF feature really works; if it doesn't we drive on with
default resolve_btfids behaviour for modules. Thanks!
Alan
>> + }
>> + if (!base_btf) {
>> + optp.btf_sec = BTF_ELF_SEC;
>> + path = obj->base_btf_path;
>> + base_btf = btf__parse_opts(path, &optp);
>> + }
>> err = libbpf_get_error(base_btf);
>> if (err) {
>> pr_err("FAILED: load base BTF from %s: %s\n",
>> - obj->base_btf_path, strerror(-err));
>> + path, strerror(-err));
>> return -1;
>> }
>> }
>
> [...]
