Re: [PATCH] libbpf: fix readelf output parsing on powerpc with recent binutils
On Thu, 2019-12-12 at 11:53 +1100, Michael Ellerman wrote: > Thadeu Lima de Souza Cascardo writes: [...] > > This is a patch on binutils carried by Fedora: > > > > https://src.fedoraproject.org/rpms/binutils/c/b8265c46f7ddae23a792ee8306fbaaeacba83bf8 > > > > " b8265c Have readelf display extra symbol information at the end of the > > line. " > > > > It has the following comment: > > > > # FIXME:The proper fix would be to update the scripts that are expecting > > # a fixed output from readelf. But it seems that some of them are > > # no longer being maintained. > > > > This commit is from 2017, had it been on binutils upstream, maybe the > > situation > > right now would be different. > > Bleeping bleep. > > Looks like it was actually ruby that was the original problem: > > https://bugzilla.redhat.com/show_bug.cgi?id=1479302 > > > Why it wasn't hacked around in the ruby package I don't know, doing it in > the distro binutils package is not ideal. That wouldn't help people building Ruby from upstream. Any tool generating tabular output like this should add new fields at the end (or show them only if requested), since there are bound to be scripts that parse the output like this. So I think Fedora's change to readelf was reasonable, but should have been pushed upstream as soon as possible. Now everyone is going to have to deal with both formats. Ben. -- Ben Hutchings Horngren's Observation: Among economists, the real world is often a special case. signature.asc Description: This is a digitally signed message part
Re: [PATCH] libbpf: fix readelf output parsing on powerpc with recent binutils
Thadeu Lima de Souza Cascardo writes:
> On Wed, Dec 11, 2019 at 09:33:53AM -0600, Justin Forbes wrote:
>> On Tue, Dec 10, 2019 at 4:26 PM Thadeu Lima de Souza Cascardo
>> wrote:
>> >
>> > On Tue, Dec 10, 2019 at 12:58:33PM -0600, Justin Forbes wrote:
>> > > On Mon, Dec 2, 2019 at 3:37 AM Daniel Borkmann
>> > > wrote:
>> > > >
>> > > > On Mon, Dec 02, 2019 at 04:53:26PM +1100, Michael Ellerman wrote:
>> > > > > Aurelien Jarno writes:
>> > > > > > On powerpc with recent versions of binutils, readelf outputs an
>> > > > > > extra
>> > > > > > field when dumping the symbols of an object file. For example:
>> > > > > >
>> > > > > > 35: 083896 FUNCLOCAL DEFAULT
>> > > > > > [: 8] 1 btf_is_struct
>> > > > > >
>> > > > > > The extra "[: 8]" prevents the GLOBAL_SYM_COUNT
>> > > > > > variable to
>> > > > > > be computed correctly and causes the checkabi target to fail.
>> > > > > >
>> > > > > > Fix that by looking for the symbol name in the last field instead
>> > > > > > of the
>> > > > > > 8th one. This way it should also cope with future extra fields.
>> > > > > >
>> > > > > > Signed-off-by: Aurelien Jarno
>> > > > > > ---
>> > > > > > tools/lib/bpf/Makefile | 4 ++--
>> > > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
>> > > > >
>> > > > > Thanks for fixing that, it's been on my very long list of test
>> > > > > failures
>> > > > > for a while.
>> > > > >
>> > > > > Tested-by: Michael Ellerman
>> > > >
>> > > > Looks good & also continues to work on x86. Applied, thanks!
>> > >
>> > > This actually seems to break horribly on PPC64le with binutils 2.33.1
>> > > resulting in:
>> > > Warning: Num of global symbols in sharedobjs/libbpf-in.o (32) does NOT
>> > > match with num of versioned symbols in libbpf.so (184). Please make
>> > > sure all LIBBPF_API symbols are versioned in libbpf.map.
>> > >
>> > > This is the only arch that fails, with x86/arm/aarch64/s390 all
>> > > building fine. Reverting this patch allows successful build across
>> > > all arches.
>> > >
>> > > Justin
>> >
>> > Well, I ended up debugging this same issue and had the same fix as Jarno's
>> > when
>> > I noticed his fix was already applied.
>> >
>> > I just installed a system with the latest binutils, 2.33.1, and it still
>> > breaks
>> > without such fix. Can you tell what is the output of the following command
>> > on
>> > your system?
>> >
>> > readelf -s --wide tools/lib/bpf/sharedobjs/libbpf-in.o | cut -d "@" -f1 |
>> > sed 's/_v[0-9]_[0-9]_[0-9].*//' | awk '/GLOBAL/ && /DEFAULT/ && !/UND/
>> > {print $0}'
>> >
>>
>> readelf -s --wide tools/lib/bpf/sharedobjs/libbpf-in.o | cut -d "@"
>> -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | awk '/GLOBAL/ && /DEFAULT/ &&
>> !/UND/ {print $0}'
>>373: 000141bc 1376 FUNCGLOBAL DEFAULT1
>> libbpf_num_possible_cpus [: 8]
>>375: 0001869c 176 FUNCGLOBAL DEFAULT1 btf__free
>> [: 8]
> [...]
>
> This is a patch on binutils carried by Fedora:
>
> https://src.fedoraproject.org/rpms/binutils/c/b8265c46f7ddae23a792ee8306fbaaeacba83bf8
>
> " b8265c Have readelf display extra symbol information at the end of the
> line. "
>
> It has the following comment:
>
> # FIXME:The proper fix would be to update the scripts that are expecting
> # a fixed output from readelf. But it seems that some of them are
> # no longer being maintained.
>
> This commit is from 2017, had it been on binutils upstream, maybe the
> situation
> right now would be different.
Bleeping bleep.
Looks like it was actually ruby that was the original problem:
https://bugzilla.redhat.com/show_bug.cgi?id=1479302
Why it wasn't hacked around in the ruby package I don't know, doing it in
the distro binutils package is not ideal.
cheers
Re: [PATCH] libbpf: fix readelf output parsing on powerpc with recent binutils
On Wed, Dec 11, 2019 at 10:01 AM Thadeu Lima de Souza Cascardo
wrote:
>
> On Wed, Dec 11, 2019 at 09:33:53AM -0600, Justin Forbes wrote:
> > On Tue, Dec 10, 2019 at 4:26 PM Thadeu Lima de Souza Cascardo
> > wrote:
> > >
> > > On Tue, Dec 10, 2019 at 12:58:33PM -0600, Justin Forbes wrote:
> > > > On Mon, Dec 2, 2019 at 3:37 AM Daniel Borkmann
> > > > wrote:
> > > > >
> > > > > On Mon, Dec 02, 2019 at 04:53:26PM +1100, Michael Ellerman wrote:
> > > > > > Aurelien Jarno writes:
> > > > > > > On powerpc with recent versions of binutils, readelf outputs an
> > > > > > > extra
> > > > > > > field when dumping the symbols of an object file. For example:
> > > > > > >
> > > > > > > 35: 083896 FUNCLOCAL DEFAULT
> > > > > > > [: 8] 1 btf_is_struct
> > > > > > >
> > > > > > > The extra "[: 8]" prevents the GLOBAL_SYM_COUNT
> > > > > > > variable to
> > > > > > > be computed correctly and causes the checkabi target to fail.
> > > > > > >
> > > > > > > Fix that by looking for the symbol name in the last field instead
> > > > > > > of the
> > > > > > > 8th one. This way it should also cope with future extra fields.
> > > > > > >
> > > > > > > Signed-off-by: Aurelien Jarno
> > > > > > > ---
> > > > > > > tools/lib/bpf/Makefile | 4 ++--
> > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > Thanks for fixing that, it's been on my very long list of test
> > > > > > failures
> > > > > > for a while.
> > > > > >
> > > > > > Tested-by: Michael Ellerman
> > > > >
> > > > > Looks good & also continues to work on x86. Applied, thanks!
> > > >
> > > > This actually seems to break horribly on PPC64le with binutils 2.33.1
> > > > resulting in:
> > > > Warning: Num of global symbols in sharedobjs/libbpf-in.o (32) does NOT
> > > > match with num of versioned symbols in libbpf.so (184). Please make
> > > > sure all LIBBPF_API symbols are versioned in libbpf.map.
> > > >
> > > > This is the only arch that fails, with x86/arm/aarch64/s390 all
> > > > building fine. Reverting this patch allows successful build across
> > > > all arches.
> > > >
> > > > Justin
> > >
> > > Well, I ended up debugging this same issue and had the same fix as
> > > Jarno's when
> > > I noticed his fix was already applied.
> > >
> > > I just installed a system with the latest binutils, 2.33.1, and it still
> > > breaks
> > > without such fix. Can you tell what is the output of the following
> > > command on
> > > your system?
> > >
> > > readelf -s --wide tools/lib/bpf/sharedobjs/libbpf-in.o | cut -d "@" -f1 |
> > > sed 's/_v[0-9]_[0-9]_[0-9].*//' | awk '/GLOBAL/ && /DEFAULT/ && !/UND/
> > > {print $0}'
> > >
> >
> > readelf -s --wide tools/lib/bpf/sharedobjs/libbpf-in.o | cut -d "@"
> > -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | awk '/GLOBAL/ && /DEFAULT/ &&
> > !/UND/ {print $0}'
> >373: 000141bc 1376 FUNCGLOBAL DEFAULT1
> > libbpf_num_possible_cpus [: 8]
> >375: 0001869c 176 FUNCGLOBAL DEFAULT1 btf__free
> > [: 8]
> [...]
>
> This is a patch on binutils carried by Fedora:
>
> https://src.fedoraproject.org/rpms/binutils/c/b8265c46f7ddae23a792ee8306fbaaeacba83bf8
>
> " b8265c Have readelf display extra symbol information at the end of the
> line. "
>
> It has the following comment:
>
> # FIXME:The proper fix would be to update the scripts that are expecting
> # a fixed output from readelf. But it seems that some of them are
> # no longer being maintained.
>
> This commit is from 2017, had it been on binutils upstream, maybe the
> situation
> right now would be different.
>
> Honestly, it seems the best way out is to filter the other information in the
> libbpf Makefile.
>
> Does the following patch work for you?
>
>
> diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
> index 56ce6292071b..e6f99484d7d5 100644
> --- a/tools/lib/bpf/Makefile
> +++ b/tools/lib/bpf/Makefile
> @@ -145,6 +145,7 @@ PC_FILE := $(addprefix $(OUTPUT),$(PC_FILE))
>
> GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN_SHARED) | \
>cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' |
> \
> + sed 's/\[.*\]//' | \
>awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$8}'
> | \
>sort -u | wc -l)
> VERSIONED_SYM_COUNT = $(shell readelf -s --wide $(OUTPUT)libbpf.so | \
> @@ -217,6 +218,7 @@ check_abi: $(OUTPUT)libbpf.so
> "versioned in $(VERSION_SCRIPT)." >&2; \
> readelf -s --wide $(OUTPUT)libbpf-in.o | \
> cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | \
> + sed 's/\[.*\]//' | \
> awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$8}'| \
> sort -u > $(OUTPUT)libbpf_global_syms.tmp; \
> readelf -s --wide
Re: [PATCH] libbpf: fix readelf output parsing on powerpc with recent binutils
On Wed, Dec 11, 2019 at 09:33:53AM -0600, Justin Forbes wrote:
> On Tue, Dec 10, 2019 at 4:26 PM Thadeu Lima de Souza Cascardo
> wrote:
> >
> > On Tue, Dec 10, 2019 at 12:58:33PM -0600, Justin Forbes wrote:
> > > On Mon, Dec 2, 2019 at 3:37 AM Daniel Borkmann
> > > wrote:
> > > >
> > > > On Mon, Dec 02, 2019 at 04:53:26PM +1100, Michael Ellerman wrote:
> > > > > Aurelien Jarno writes:
> > > > > > On powerpc with recent versions of binutils, readelf outputs an
> > > > > > extra
> > > > > > field when dumping the symbols of an object file. For example:
> > > > > >
> > > > > > 35: 083896 FUNCLOCAL DEFAULT
> > > > > > [: 8] 1 btf_is_struct
> > > > > >
> > > > > > The extra "[: 8]" prevents the GLOBAL_SYM_COUNT
> > > > > > variable to
> > > > > > be computed correctly and causes the checkabi target to fail.
> > > > > >
> > > > > > Fix that by looking for the symbol name in the last field instead
> > > > > > of the
> > > > > > 8th one. This way it should also cope with future extra fields.
> > > > > >
> > > > > > Signed-off-by: Aurelien Jarno
> > > > > > ---
> > > > > > tools/lib/bpf/Makefile | 4 ++--
> > > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > >
> > > > > Thanks for fixing that, it's been on my very long list of test
> > > > > failures
> > > > > for a while.
> > > > >
> > > > > Tested-by: Michael Ellerman
> > > >
> > > > Looks good & also continues to work on x86. Applied, thanks!
> > >
> > > This actually seems to break horribly on PPC64le with binutils 2.33.1
> > > resulting in:
> > > Warning: Num of global symbols in sharedobjs/libbpf-in.o (32) does NOT
> > > match with num of versioned symbols in libbpf.so (184). Please make
> > > sure all LIBBPF_API symbols are versioned in libbpf.map.
> > >
> > > This is the only arch that fails, with x86/arm/aarch64/s390 all
> > > building fine. Reverting this patch allows successful build across
> > > all arches.
> > >
> > > Justin
> >
> > Well, I ended up debugging this same issue and had the same fix as Jarno's
> > when
> > I noticed his fix was already applied.
> >
> > I just installed a system with the latest binutils, 2.33.1, and it still
> > breaks
> > without such fix. Can you tell what is the output of the following command
> > on
> > your system?
> >
> > readelf -s --wide tools/lib/bpf/sharedobjs/libbpf-in.o | cut -d "@" -f1 |
> > sed 's/_v[0-9]_[0-9]_[0-9].*//' | awk '/GLOBAL/ && /DEFAULT/ && !/UND/
> > {print $0}'
> >
>
> readelf -s --wide tools/lib/bpf/sharedobjs/libbpf-in.o | cut -d "@"
> -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | awk '/GLOBAL/ && /DEFAULT/ &&
> !/UND/ {print $0}'
>373: 000141bc 1376 FUNCGLOBAL DEFAULT1
> libbpf_num_possible_cpus [: 8]
>375: 0001869c 176 FUNCGLOBAL DEFAULT1 btf__free
> [: 8]
[...]
This is a patch on binutils carried by Fedora:
https://src.fedoraproject.org/rpms/binutils/c/b8265c46f7ddae23a792ee8306fbaaeacba83bf8
" b8265c Have readelf display extra symbol information at the end of the line. "
It has the following comment:
# FIXME:The proper fix would be to update the scripts that are expecting
# a fixed output from readelf. But it seems that some of them are
# no longer being maintained.
This commit is from 2017, had it been on binutils upstream, maybe the situation
right now would be different.
Honestly, it seems the best way out is to filter the other information in the
libbpf Makefile.
Does the following patch work for you?
diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index 56ce6292071b..e6f99484d7d5 100644
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@ -145,6 +145,7 @@ PC_FILE := $(addprefix $(OUTPUT),$(PC_FILE))
GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN_SHARED) | \
cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | \
+ sed 's/\[.*\]//' | \
awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$8}' | \
sort -u | wc -l)
VERSIONED_SYM_COUNT = $(shell readelf -s --wide $(OUTPUT)libbpf.so | \
@@ -217,6 +218,7 @@ check_abi: $(OUTPUT)libbpf.so
"versioned in $(VERSION_SCRIPT)." >&2; \
readelf -s --wide $(OUTPUT)libbpf-in.o | \
cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | \
+ sed 's/\[.*\]//' | \
awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$8}'| \
sort -u > $(OUTPUT)libbpf_global_syms.tmp; \
readelf -s --wide $(OUTPUT)libbpf.so | \
Re: [PATCH] libbpf: fix readelf output parsing on powerpc with recent binutils
On 2019-12-11 09:33, Justin Forbes wrote:
> On Tue, Dec 10, 2019 at 4:26 PM Thadeu Lima de Souza Cascardo
> wrote:
> >
> > On Tue, Dec 10, 2019 at 12:58:33PM -0600, Justin Forbes wrote:
> > > On Mon, Dec 2, 2019 at 3:37 AM Daniel Borkmann
> > > wrote:
> > > >
> > > > On Mon, Dec 02, 2019 at 04:53:26PM +1100, Michael Ellerman wrote:
> > > > > Aurelien Jarno writes:
> > > > > > On powerpc with recent versions of binutils, readelf outputs an
> > > > > > extra
> > > > > > field when dumping the symbols of an object file. For example:
> > > > > >
> > > > > > 35: 083896 FUNCLOCAL DEFAULT
> > > > > > [: 8] 1 btf_is_struct
> > > > > >
> > > > > > The extra "[: 8]" prevents the GLOBAL_SYM_COUNT
> > > > > > variable to
> > > > > > be computed correctly and causes the checkabi target to fail.
> > > > > >
> > > > > > Fix that by looking for the symbol name in the last field instead
> > > > > > of the
> > > > > > 8th one. This way it should also cope with future extra fields.
> > > > > >
> > > > > > Signed-off-by: Aurelien Jarno
> > > > > > ---
> > > > > > tools/lib/bpf/Makefile | 4 ++--
> > > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > >
> > > > > Thanks for fixing that, it's been on my very long list of test
> > > > > failures
> > > > > for a while.
> > > > >
> > > > > Tested-by: Michael Ellerman
> > > >
> > > > Looks good & also continues to work on x86. Applied, thanks!
> > >
> > > This actually seems to break horribly on PPC64le with binutils 2.33.1
> > > resulting in:
> > > Warning: Num of global symbols in sharedobjs/libbpf-in.o (32) does NOT
> > > match with num of versioned symbols in libbpf.so (184). Please make
> > > sure all LIBBPF_API symbols are versioned in libbpf.map.
> > >
> > > This is the only arch that fails, with x86/arm/aarch64/s390 all
> > > building fine. Reverting this patch allows successful build across
> > > all arches.
> > >
> > > Justin
> >
> > Well, I ended up debugging this same issue and had the same fix as Jarno's
> > when
> > I noticed his fix was already applied.
> >
> > I just installed a system with the latest binutils, 2.33.1, and it still
> > breaks
> > without such fix. Can you tell what is the output of the following command
> > on
> > your system?
> >
> > readelf -s --wide tools/lib/bpf/sharedobjs/libbpf-in.o | cut -d "@" -f1 |
> > sed 's/_v[0-9]_[0-9]_[0-9].*//' | awk '/GLOBAL/ && /DEFAULT/ && !/UND/
> > {print $0}'
> >
>
> readelf -s --wide tools/lib/bpf/sharedobjs/libbpf-in.o | cut -d "@"
> -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | awk '/GLOBAL/ && /DEFAULT/ &&
> !/UND/ {print $0}'
>373: 000141bc 1376 FUNCGLOBAL DEFAULT1
> libbpf_num_possible_cpus [: 8]
>375: 0001869c 176 FUNCGLOBAL DEFAULT1 btf__free
> [: 8]
It seems that in your case the localentry part is added after the symbol
name. That doesn't match what is done in upstream binutils:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=binutils/readelf.c;hb=refs/heads/master#l11485
Which version of binutils are you using? It looks like your version has
been modified to workaround this exact issue.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Re: [PATCH] libbpf: fix readelf output parsing on powerpc with recent binutils
On Tue, Dec 10, 2019 at 4:26 PM Thadeu Lima de Souza Cascardo
wrote:
>
> On Tue, Dec 10, 2019 at 12:58:33PM -0600, Justin Forbes wrote:
> > On Mon, Dec 2, 2019 at 3:37 AM Daniel Borkmann wrote:
> > >
> > > On Mon, Dec 02, 2019 at 04:53:26PM +1100, Michael Ellerman wrote:
> > > > Aurelien Jarno writes:
> > > > > On powerpc with recent versions of binutils, readelf outputs an extra
> > > > > field when dumping the symbols of an object file. For example:
> > > > >
> > > > > 35: 083896 FUNCLOCAL DEFAULT [:
> > > > > 8] 1 btf_is_struct
> > > > >
> > > > > The extra "[: 8]" prevents the GLOBAL_SYM_COUNT variable
> > > > > to
> > > > > be computed correctly and causes the checkabi target to fail.
> > > > >
> > > > > Fix that by looking for the symbol name in the last field instead of
> > > > > the
> > > > > 8th one. This way it should also cope with future extra fields.
> > > > >
> > > > > Signed-off-by: Aurelien Jarno
> > > > > ---
> > > > > tools/lib/bpf/Makefile | 4 ++--
> > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > Thanks for fixing that, it's been on my very long list of test failures
> > > > for a while.
> > > >
> > > > Tested-by: Michael Ellerman
> > >
> > > Looks good & also continues to work on x86. Applied, thanks!
> >
> > This actually seems to break horribly on PPC64le with binutils 2.33.1
> > resulting in:
> > Warning: Num of global symbols in sharedobjs/libbpf-in.o (32) does NOT
> > match with num of versioned symbols in libbpf.so (184). Please make
> > sure all LIBBPF_API symbols are versioned in libbpf.map.
> >
> > This is the only arch that fails, with x86/arm/aarch64/s390 all
> > building fine. Reverting this patch allows successful build across
> > all arches.
> >
> > Justin
>
> Well, I ended up debugging this same issue and had the same fix as Jarno's
> when
> I noticed his fix was already applied.
>
> I just installed a system with the latest binutils, 2.33.1, and it still
> breaks
> without such fix. Can you tell what is the output of the following command on
> your system?
>
> readelf -s --wide tools/lib/bpf/sharedobjs/libbpf-in.o | cut -d "@" -f1 | sed
> 's/_v[0-9]_[0-9]_[0-9].*//' | awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $0}'
>
readelf -s --wide tools/lib/bpf/sharedobjs/libbpf-in.o | cut -d "@"
-f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | awk '/GLOBAL/ && /DEFAULT/ &&
!/UND/ {print $0}'
373: 000141bc 1376 FUNCGLOBAL DEFAULT1
libbpf_num_possible_cpus [: 8]
375: 0001869c 176 FUNCGLOBAL DEFAULT1 btf__free
[: 8]
377: 0001093c84 FUNCGLOBAL DEFAULT1
bpf_object__find_map_by_offset [: 8]
378: 00016288 100 FUNCGLOBAL DEFAULT1
bpf_prog_get_next_id [: 8]
379: 000103c0 104 FUNCGLOBAL DEFAULT1
bpf_map__priv [: 8]
380: e158 180 FUNCGLOBAL DEFAULT1
bpf_object__pin [: 8]
381: 000102f8 200 FUNCGLOBAL DEFAULT1
bpf_map__set_priv [: 8]
382: 0001874c 380 FUNCGLOBAL DEFAULT1 btf__new
[: 8]
384: 0002238c 1372 FUNCGLOBAL DEFAULT1 xsk_umem__create
385: 000106fc 116 FUNCGLOBAL DEFAULT1
bpf_map__next [: 8]
387: 000162ec 100 FUNCGLOBAL DEFAULT1
bpf_map_get_next_id [: 8]
389: f57484 FUNCGLOBAL DEFAULT1
bpf_program__is_xdp [: 8]
390: 00011e14 392 FUNCGLOBAL DEFAULT1
bpf_program__attach_tracepoint [: 8]
391: 00016534 196 FUNCGLOBAL DEFAULT1
bpf_obj_get_info_by_fd [: 8]
392: cf64 324 FUNCGLOBAL DEFAULT1
bpf_program__unpin_instance [: 8]
393: d818 456 FUNCGLOBAL DEFAULT1
bpf_map__unpin [: 8]
395: efe064 FUNCGLOBAL DEFAULT1 bpf_program__set_type
396: 00010e94 696 FUNCGLOBAL DEFAULT1
bpf_program__attach_perf_event [: 8]
397: 0001a774 136 FUNCGLOBAL DEFAULT1
btf_ext__reloc_func_info [: 8]
398: 00014bc8 236 FUNCGLOBAL DEFAULT1
bpf_create_map_name [: 8]
402: 000228e8 160 FUNCGLOBAL DEFAULT1 xsk_umem__create
403: 00021f1c72 FUNCGLOBAL DEFAULT1 xsk_socket__fd
404: 0001a8ec 536 FUNCGLOBAL DEFAULT1 btf__dedup
[: 8]
405: eadc 180 FUNCGLOBAL DEFAULT1
bpf_program__set_priv [: 8]
409: c540 144 FUNCGLOBAL DEFAULT1
bpf_object__open_file [: 8]
410: 000121a8 416 FUNCGLOBAL DEFAULT1
bpf_program__attach_trace [: 8]
415: d51c 764 FUNCGLOBAL DEFAULT1
bpf_map__pin [: 8]
416: 000154d0 212 FUNCGLOBAL DEFAULT1
bpf_load_program [: 8]
418: 00010810 192 FUNCGLOBAL DEFAULT1
bpf_object__find_map_by_name [: 8]
420: 00012348 580 FUNCGLOBAL DEFAULT1
bpf_perf_event_read_simple [: 8]
421: 000191e8 220 FUNCGLOBAL
Re: [PATCH] libbpf: fix readelf output parsing on powerpc with recent binutils
On Tue, Dec 10, 2019 at 12:58:33PM -0600, Justin Forbes wrote:
> On Mon, Dec 2, 2019 at 3:37 AM Daniel Borkmann wrote:
> >
> > On Mon, Dec 02, 2019 at 04:53:26PM +1100, Michael Ellerman wrote:
> > > Aurelien Jarno writes:
> > > > On powerpc with recent versions of binutils, readelf outputs an extra
> > > > field when dumping the symbols of an object file. For example:
> > > >
> > > > 35: 083896 FUNCLOCAL DEFAULT [: 8]
> > > > 1 btf_is_struct
> > > >
> > > > The extra "[: 8]" prevents the GLOBAL_SYM_COUNT variable to
> > > > be computed correctly and causes the checkabi target to fail.
> > > >
> > > > Fix that by looking for the symbol name in the last field instead of the
> > > > 8th one. This way it should also cope with future extra fields.
> > > >
> > > > Signed-off-by: Aurelien Jarno
> > > > ---
> > > > tools/lib/bpf/Makefile | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > Thanks for fixing that, it's been on my very long list of test failures
> > > for a while.
> > >
> > > Tested-by: Michael Ellerman
> >
> > Looks good & also continues to work on x86. Applied, thanks!
>
> This actually seems to break horribly on PPC64le with binutils 2.33.1
> resulting in:
> Warning: Num of global symbols in sharedobjs/libbpf-in.o (32) does NOT
> match with num of versioned symbols in libbpf.so (184). Please make
> sure all LIBBPF_API symbols are versioned in libbpf.map.
>
> This is the only arch that fails, with x86/arm/aarch64/s390 all
> building fine. Reverting this patch allows successful build across
> all arches.
>
> Justin
Well, I ended up debugging this same issue and had the same fix as Jarno's when
I noticed his fix was already applied.
I just installed a system with the latest binutils, 2.33.1, and it still breaks
without such fix. Can you tell what is the output of the following command on
your system?
readelf -s --wide tools/lib/bpf/sharedobjs/libbpf-in.o | cut -d "@" -f1 | sed
's/_v[0-9]_[0-9]_[0-9].*//' | awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $0}'
Cascardo.
Re: [PATCH] libbpf: fix readelf output parsing on powerpc with recent binutils
On Mon, Dec 2, 2019 at 3:37 AM Daniel Borkmann wrote: > > On Mon, Dec 02, 2019 at 04:53:26PM +1100, Michael Ellerman wrote: > > Aurelien Jarno writes: > > > On powerpc with recent versions of binutils, readelf outputs an extra > > > field when dumping the symbols of an object file. For example: > > > > > > 35: 083896 FUNCLOCAL DEFAULT [: 8] > > > 1 btf_is_struct > > > > > > The extra "[: 8]" prevents the GLOBAL_SYM_COUNT variable to > > > be computed correctly and causes the checkabi target to fail. > > > > > > Fix that by looking for the symbol name in the last field instead of the > > > 8th one. This way it should also cope with future extra fields. > > > > > > Signed-off-by: Aurelien Jarno > > > --- > > > tools/lib/bpf/Makefile | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > Thanks for fixing that, it's been on my very long list of test failures > > for a while. > > > > Tested-by: Michael Ellerman > > Looks good & also continues to work on x86. Applied, thanks! This actually seems to break horribly on PPC64le with binutils 2.33.1 resulting in: Warning: Num of global symbols in sharedobjs/libbpf-in.o (32) does NOT match with num of versioned symbols in libbpf.so (184). Please make sure all LIBBPF_API symbols are versioned in libbpf.map. This is the only arch that fails, with x86/arm/aarch64/s390 all building fine. Reverting this patch allows successful build across all arches. Justin
Re: [PATCH] libbpf: fix readelf output parsing on powerpc with recent binutils
On Mon, Dec 02, 2019 at 04:53:26PM +1100, Michael Ellerman wrote: > Aurelien Jarno writes: > > On powerpc with recent versions of binutils, readelf outputs an extra > > field when dumping the symbols of an object file. For example: > > > > 35: 083896 FUNCLOCAL DEFAULT [: 8] > > 1 btf_is_struct > > > > The extra "[: 8]" prevents the GLOBAL_SYM_COUNT variable to > > be computed correctly and causes the checkabi target to fail. > > > > Fix that by looking for the symbol name in the last field instead of the > > 8th one. This way it should also cope with future extra fields. > > > > Signed-off-by: Aurelien Jarno > > --- > > tools/lib/bpf/Makefile | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > Thanks for fixing that, it's been on my very long list of test failures > for a while. > > Tested-by: Michael Ellerman Looks good & also continues to work on x86. Applied, thanks!
Re: [PATCH] libbpf: fix readelf output parsing on powerpc with recent binutils
Aurelien Jarno writes:
> On powerpc with recent versions of binutils, readelf outputs an extra
> field when dumping the symbols of an object file. For example:
>
> 35: 083896 FUNCLOCAL DEFAULT [: 8] 1
> btf_is_struct
>
> The extra "[: 8]" prevents the GLOBAL_SYM_COUNT variable to
> be computed correctly and causes the checkabi target to fail.
>
> Fix that by looking for the symbol name in the last field instead of the
> 8th one. This way it should also cope with future extra fields.
>
> Signed-off-by: Aurelien Jarno
> ---
> tools/lib/bpf/Makefile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Thanks for fixing that, it's been on my very long list of test failures
for a while.
Tested-by: Michael Ellerman
cheers
> diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
> index 99425d0be6ff..333900cf3f4f 100644
> --- a/tools/lib/bpf/Makefile
> +++ b/tools/lib/bpf/Makefile
> @@ -147,7 +147,7 @@ TAGS_PROG := $(if $(shell which etags
> 2>/dev/null),etags,ctags)
>
> GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN_SHARED) | \
> cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | \
> -awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$8}' | \
> +awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$NF}' |
> \
> sort -u | wc -l)
> VERSIONED_SYM_COUNT = $(shell readelf -s --wide $(OUTPUT)libbpf.so | \
> grep -Eo '[^ ]+@LIBBPF_' | cut -d@ -f1 | sort -u
> | wc -l)
> @@ -216,7 +216,7 @@ check_abi: $(OUTPUT)libbpf.so
>"versioned in $(VERSION_SCRIPT)." >&2; \
> readelf -s --wide $(OUTPUT)libbpf-in.o | \
> cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | \
> - awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$8}'| \
> + awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$NF}'| \
> sort -u > $(OUTPUT)libbpf_global_syms.tmp; \
> readelf -s --wide $(OUTPUT)libbpf.so | \
> grep -Eo '[^ ]+@LIBBPF_' | cut -d@ -f1 | \
> --
> 2.24.0
