On 31/01/2023 01:04, Arnaldo Carvalho de Melo wrote:
> Em Mon, Jan 30, 2023 at 09:25:17PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Mon, Jan 30, 2023 at 10:37:56PM +0000, Alan Maguire escreveu:
>>> On 30/01/2023 20:23, Arnaldo Carvalho de Melo wrote:
>>>> Em Mon, Jan 30, 2023 at 05:10:51PM -0300, Arnaldo Carvalho de Melo escreveu:
>>>>> +++ b/dwarves.h
>>>>> @@ -262,6 +262,7 @@ struct cu {
>>>>> uint8_t has_addr_info:1;
>>>>> uint8_t uses_global_strings:1;
>>>>> uint8_t little_endian:1;
>>>>> + uint8_t nr_register_params;
>>>>> uint16_t language;
>>>>> unsigned long nr_inline_expansions;
>>>>> size_t size_inline_expansions;
>>>>
>>
>>> Thanks for this, never thought of cross-builds to be honest!
>>
>>> Tested just now on x86_64 and aarch64 at my end, just ran
>>> into one small thing on one system; turns out EM_RISCV isn't
>>> defined if using a very old elf.h; below works around this
>>> (dwarves otherwise builds fine on this system).
>>
>> Ok, will add it and will test with containers for older distros too.
>
> Its on the 'next' branch, so that it gets tested in the libbpf github
> repo at:
>
> https://github.com/libbpf/libbpf/actions/workflows/pahole.yml
>
> It failed yesterday and today due to problems with the installation of
> llvm, probably tomorrow it'll be back working as I saw some
> notifications floating by.
>
> I added the conditional EM_RISCV definition as well as removed the dup
> iterator that Jiri noticed.
>
Thanks again Arnaldo! I've hit an issue with this series in
BTF encoding of kfuncs; specifically we see some kfuncs missing
from the BTF representation, and as a result:
WARN: resolve_btfids: unresolved symbol bpf_xdp_metadata_rx_hash
WARN: resolve_btfids: unresolved symbol bpf_task_kptr_get
WARN: resolve_btfids: unresolved symbol bpf_ct_change_status
Not sure why I didn't notice this previously.
The problem is the DWARF - and therefore BTF - generated for a function like
int bpf_xdp_metadata_rx_hash(const struct xdp_md *ctx, u32 *hash)
{
return -EOPNOTSUPP;
}
looks like this:
<8af83a2> DW_AT_external : 1
<8af83a2> DW_AT_name : (indirect string, offset: 0x358bdc): bpf_xdp_metadata_rx_hash
<8af83a6> DW_AT_decl_file : 5
<8af83a7> DW_AT_decl_line : 737
<8af83a9> DW_AT_decl_column : 5
<8af83aa> DW_AT_prototyped : 1
<8af83aa> DW_AT_type : <0x8ad8547>
<8af83ae> DW_AT_sibling : <0x8af83cd>
<2><8af83b2>: Abbrev Number: 38 (DW_TAG_formal_parameter)
<8af83b3> DW_AT_name : ctx
<8af83b7> DW_AT_decl_file : 5
<8af83b8> DW_AT_decl_line : 737
<8af83ba> DW_AT_decl_column : 51
<8af83bb> DW_AT_type : <0x8af421d>
<2><8af83bf>: Abbrev Number: 35 (DW_TAG_formal_parameter)
<8af83c0> DW_AT_name : (indirect string, offset: 0x27f6a2): hash
<8af83c4> DW_AT_decl_file : 5
<8af83c5> DW_AT_decl_line : 737
<8af83c7> DW_AT_decl_column : 61
<8af83c8> DW_AT_type : <0x8adc424>
...and because there are no further abstract origin references
with location information either, we classify it as lacking
locations for (some of) the parameters, and as a result
we skip BTF encoding. We can work around that by doing this:
__attribute__ ((optimize("O0"))) int bpf_xdp_metadata_rx_hash(const struct xdp_md *ctx, u32 *hash)
{
return -EOPNOTSUPP;
}
Should we #define some kind of "kfunc" prefix equivalent to the
above to handle these cases in include/linux/bpf.h perhaps?
If that makes sense, I'll send bpf-next patches to cover the
set of kfuncs.
The other thing we might want to do is bump the libbpf version
for dwarves 1.25, what do you think? I've tested with libbpf 1.1
and aside from the above issue all looks good (there's a few dedup
improvements that this version will give us). I can send a patch for
the libbpf update if that makes sense.
Thanks!
Alan
> Thanks,
>
> - Arnaldo
>
>>> diff --git a/dwarf_loader.c b/dwarf_loader.c
>>> index dba2d37..47a3bc2 100644
>>> --- a/dwarf_loader.c
>>> +++ b/dwarf_loader.c
>>> @@ -992,6 +992,11 @@ static struct class_member *class_member__new(Dwarf_Die *die, struct cu *c
>>> return member;
>>> }
>>>
>>> +/* for older elf.h */
>>> +#ifndef EM_RISCV
>>> +#define EM_RISCV 243
>>> +#endif
>>> +
>>> /* How many function parameters are passed via registers? Used below in
>>> * determining if an argument has been optimized out or if it is simply
>>> * an argument > cu__nr_register_params(). Making cu__nr_register_params()
>>
>> --
>>
>> - Arnaldo
>
