All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Quentin Monnet <quentin@isovalent.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>, bpf <bpf@vger.kernel.org>,
	Network Development <netdev@vger.kernel.org>,
	Andrii Nakryiko <andriin@fb.com>
Subject: Re: [PATCH bpf-next] tools: bpftool: restore message on failure to guess program type
Date: Thu, 12 Mar 2020 18:11:54 -0700	[thread overview]
Message-ID: <CAADnVQ+i_y89KkiGe2aZbDstvND17esMCz=uegCSGwq47vXsuQ@mail.gmail.com> (raw)
In-Reply-To: <20200311021205.9755-1-quentin@isovalent.com>

On Tue, Mar 10, 2020 at 7:12 PM Quentin Monnet <quentin@isovalent.com> wrote:
>
> In commit 4a3d6c6a6e4d ("libbpf: Reduce log level for custom section
> names"), log level for messages for libbpf_attach_type_by_name() and
> libbpf_prog_type_by_name() was downgraded from "info" to "debug". The
> latter function, in particular, is used by bpftool when attempting to
> load programs, and this change caused bpftool to exit with no hint or
> error message when it fails to detect the type of the program to load
> (unless "-d" option was provided).
>
> To help users understand why bpftool fails to load the program, let's do
> a second run of the function with log level in "debug" mode in case of
> failure.
>
> Before:
>
>     # bpftool prog load sample_ret0.o /sys/fs/bpf/sample_ret0
>     # echo $?
>     255
>
> Or really verbose with -d flag:
>
>     # bpftool -d prog load sample_ret0.o /sys/fs/bpf/sample_ret0
>     libbpf: loading sample_ret0.o
>     libbpf: section(1) .strtab, size 134, link 0, flags 0, type=3
>     libbpf: skip section(1) .strtab
>     libbpf: section(2) .text, size 16, link 0, flags 6, type=1
>     libbpf: found program .text
>     libbpf: section(3) .debug_abbrev, size 55, link 0, flags 0, type=1
>     libbpf: skip section(3) .debug_abbrev
>     libbpf: section(4) .debug_info, size 75, link 0, flags 0, type=1
>     libbpf: skip section(4) .debug_info
>     libbpf: section(5) .rel.debug_info, size 32, link 14, flags 0, type=9
>     libbpf: skip relo .rel.debug_info(5) for section(4)
>     libbpf: section(6) .debug_str, size 150, link 0, flags 30, type=1
>     libbpf: skip section(6) .debug_str
>     libbpf: section(7) .BTF, size 155, link 0, flags 0, type=1
>     libbpf: section(8) .BTF.ext, size 80, link 0, flags 0, type=1
>     libbpf: section(9) .rel.BTF.ext, size 32, link 14, flags 0, type=9
>     libbpf: skip relo .rel.BTF.ext(9) for section(8)
>     libbpf: section(10) .debug_frame, size 40, link 0, flags 0, type=1
>     libbpf: skip section(10) .debug_frame
>     libbpf: section(11) .rel.debug_frame, size 16, link 14, flags 0, type=9
>     libbpf: skip relo .rel.debug_frame(11) for section(10)
>     libbpf: section(12) .debug_line, size 74, link 0, flags 0, type=1
>     libbpf: skip section(12) .debug_line
>     libbpf: section(13) .rel.debug_line, size 16, link 14, flags 0, type=9
>     libbpf: skip relo .rel.debug_line(13) for section(12)
>     libbpf: section(14) .symtab, size 96, link 1, flags 0, type=2
>     libbpf: looking for externs among 4 symbols...
>     libbpf: collected 0 externs total
>     libbpf: failed to guess program type from ELF section '.text'
>     libbpf: supported section(type) names are: socket sk_reuseport kprobe/ [...]
>
> After:
>
>     # bpftool prog load sample_ret0.o /sys/fs/bpf/sample_ret0
>     libbpf: failed to guess program type from ELF section '.text'
>     libbpf: supported section(type) names are: socket sk_reuseport kprobe/ [...]
>
> Signed-off-by: Quentin Monnet <quentin@isovalent.com>

Applied. Thanks

      parent reply	other threads:[~2020-03-13  1:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-11  2:12 [PATCH bpf-next] tools: bpftool: restore message on failure to guess program type Quentin Monnet
2020-03-11 23:42 ` John Fastabend
2020-03-13  1:11 ` Alexei Starovoitov [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='CAADnVQ+i_y89KkiGe2aZbDstvND17esMCz=uegCSGwq47vXsuQ@mail.gmail.com' \
    --to=alexei.starovoitov@gmail.com \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=netdev@vger.kernel.org \
    --cc=quentin@isovalent.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.