On Sun, Jul 31, 2022 at 05:26:49PM -0600, James Hilliard wrote:
> The GNU assembler generates an empty .bss section. This is a well
> established behavior in GAS that happens in all supported targets.
>
> The LLVM assembler doesn't generate an empty .bss section.
>
> bpftool chokes on the empty .bss section.
>
> Additionally in bpf_object__elf_collect the sec_desc->data is not
> initialized when a section is not recognized. In this case, this
> happens with .comment.
>
> So we must check that sec_desc->data is initialized before checking
> if the size is 0.
oops David send same change but I asked him to move the check
to bpf_object__elf_collect [1] .. but with your explanation this
fix actualy looks fine to me
jirka
[1] https://lore.kernel.org/bpf/YuKaFiZ+ksB5f0Ye@krava/
>
> Signed-off-by: James Hilliard <[email protected]>
> Cc: Jose E. Marchesi <[email protected]>
> ---
> tools/lib/bpf/libbpf.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 50d41815f431..77e3797cf75a 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -1642,6 +1642,10 @@ static int bpf_object__init_global_data_maps(struct bpf_object *obj)
> for (sec_idx = 1; sec_idx < obj->efile.sec_cnt; sec_idx++) {
> sec_desc = &obj->efile.secs[sec_idx];
>
> + /* Skip recognized sections with size 0. */
> + if (sec_desc->data && sec_desc->data->d_size == 0)
> + continue;
> +
> switch (sec_desc->sec_type) {
> case SEC_DATA:
> sec_name = elf_sec_name(obj, elf_sec_by_idx(obj, sec_idx));
> --
> 2.34.1
>
On 8/1/22 13:24, Jiri Olsa wrote:
> On Sun, Jul 31, 2022 at 05:26:49PM -0600, James Hilliard wrote:
>> The GNU assembler generates an empty .bss section. This is a well
>> established behavior in GAS that happens in all supported targets.
>>
>> The LLVM assembler doesn't generate an empty .bss section.
>>
>> bpftool chokes on the empty .bss section.
>>
>> Additionally in bpf_object__elf_collect the sec_desc->data is not
>> initialized when a section is not recognized. In this case, this
>> happens with .comment.
>>
>> So we must check that sec_desc->data is initialized before checking
>> if the size is 0.
>
> oops David send same change but I asked him to move the check
> to bpf_object__elf_collect [1] .. but with your explanation this
> fix actualy looks fine to me
FWIW, I only just got back to actually making that change. This
patch has a much better explanation than the one I sent so +1 from
me also
David
>
> jirka
>
>
> [1] https://lore.kernel.org/bpf/YuKaFiZ+ksB5f0Ye@krava/
>
>>
>> Signed-off-by: James Hilliard <[email protected]>
>> Cc: Jose E. Marchesi <[email protected]>
>> ---
>> tools/lib/bpf/libbpf.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>> index 50d41815f431..77e3797cf75a 100644
>> --- a/tools/lib/bpf/libbpf.c
>> +++ b/tools/lib/bpf/libbpf.c
>> @@ -1642,6 +1642,10 @@ static int bpf_object__init_global_data_maps(struct bpf_object *obj)
>> for (sec_idx = 1; sec_idx < obj->efile.sec_cnt; sec_idx++) {
>> sec_desc = &obj->efile.secs[sec_idx];
>>
>> + /* Skip recognized sections with size 0. */
>> + if (sec_desc->data && sec_desc->data->d_size == 0)
>> + continue;
>> +
>> switch (sec_desc->sec_type) {
>> case SEC_DATA:
>> sec_name = elf_sec_name(obj, elf_sec_by_idx(obj, sec_idx));
>> --
>> 2.34.1
>>
On Mon, Aug 01, 2022 at 03:21:58PM -0700, David Faust wrote:
>
>
> On 8/1/22 13:24, Jiri Olsa wrote:
> > On Sun, Jul 31, 2022 at 05:26:49PM -0600, James Hilliard wrote:
> >> The GNU assembler generates an empty .bss section. This is a well
> >> established behavior in GAS that happens in all supported targets.
> >>
> >> The LLVM assembler doesn't generate an empty .bss section.
> >>
> >> bpftool chokes on the empty .bss section.
> >>
> >> Additionally in bpf_object__elf_collect the sec_desc->data is not
> >> initialized when a section is not recognized. In this case, this
> >> happens with .comment.
> >>
> >> So we must check that sec_desc->data is initialized before checking
> >> if the size is 0.
> >
> > oops David send same change but I asked him to move the check
> > to bpf_object__elf_collect [1] .. but with your explanation this
> > fix actualy looks fine to me
>
> FWIW, I only just got back to actually making that change. This
> patch has a much better explanation than the one I sent so +1 from
> me also
thanks, I'm acking this one then
Acked-by: Jiri Olsa <[email protected]>
jirka
>
> David
>
> >
> > jirka
> >
> >
> > [1] https://lore.kernel.org/bpf/YuKaFiZ+ksB5f0Ye@krava/
> >
> >>
> >> Signed-off-by: James Hilliard <[email protected]>
> >> Cc: Jose E. Marchesi <[email protected]>
> >> ---
> >> tools/lib/bpf/libbpf.c | 4 ++++
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> >> index 50d41815f431..77e3797cf75a 100644
> >> --- a/tools/lib/bpf/libbpf.c
> >> +++ b/tools/lib/bpf/libbpf.c
> >> @@ -1642,6 +1642,10 @@ static int bpf_object__init_global_data_maps(struct bpf_object *obj)
> >> for (sec_idx = 1; sec_idx < obj->efile.sec_cnt; sec_idx++) {
> >> sec_desc = &obj->efile.secs[sec_idx];
> >>
> >> + /* Skip recognized sections with size 0. */
> >> + if (sec_desc->data && sec_desc->data->d_size == 0)
> >> + continue;
> >> +
> >> switch (sec_desc->sec_type) {
> >> case SEC_DATA:
> >> sec_name = elf_sec_name(obj, elf_sec_by_idx(obj, sec_idx));
> >> --
> >> 2.34.1
> >>