Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1278555
| From | "Wangnan (F)" <wangnan0@huawei.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 04/16] bpf tools: Collect map definition in bpf_object |
| Date | 2015-11-27 07:30 +0100 |
| Message-ID | <qzkHD-7CD-1@gated-at.bofh.it> (permalink) |
| References | <qylZ8-g8-7@gated-at.bofh.it> <qym8O-jw-21@gated-at.bofh.it> <qzbO1-1JG-3@gated-at.bofh.it> <qzkxX-7zh-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 2015/11/27 14:16, Wangnan (F) wrote:
>
>
> On 2015/11/27 4:56, Arnaldo Carvalho de Melo wrote:
>> Em Tue, Nov 24, 2015 at 01:36:09PM +0000, Wang Nan escreveu:
>
> [SNIP]
[SNIP]
>>> +
>>> + if ((prev < s) || (prev >= e)) {
>>> + pr_warning("error: map handler doesn't belong to object\n");
>> I wonder if this shouldn't be made pr_debug, and as well have a function
>> prefix, otherwise we may think this is related to some other kind of
>> map, so I suggest:
>> pr_debug("%s: error: map handler doesn't belong to object\n",
>> __func__);
>>
>> Or at least:
>>
>> pr_debug("BPF error: map handler doesn't belong to object\n");
>
> We always have a libbpf prefix before debug info from libbpf. Please see
>
> static __printf(1, 2) libbpf_print_fn_t __pr_warning = __base_pr;
> static __printf(1, 2) libbpf_print_fn_t __pr_info = __base_pr;
> static __printf(1, 2) libbpf_print_fn_t __pr_debug;
> #define __pr(func, fmt, ...) \
> do { \
> if ((func)) \
> (func)("libbpf: " fmt, ##__VA_ARGS__); \
> } while (0)
>
> #define pr_warning(fmt, ...) __pr(__pr_warning, fmt, ##__VA_ARGS__)
> #define pr_info(fmt, ...) __pr(__pr_info, fmt, ##__VA_ARGS__)
> #define pr_debug(fmt, ...) __pr(__pr_debug, fmt, ##__VA_ARGS__)
>
> We allow __pr_{warning,info,debug} be overwritten but the 'libbpf:'
> prefix is
> always there.
>
> Also, don't forget in perf's context libbpf is muted.
>
Sorry, Shoule be "muted in most case"...
Here's an example:
$ sudo ./perf record -v -e ./test_bpf_base.c ls
...
ude/uapi -Iinclude/generated/uapi -include
/home/w00229757/linux-hydrogen/include/linux/kconfig.h
set env: WORKING_DIR=/lib/modules/4.3.0-rc4+/build
set env: CLANG_SOURCE=/home/w00229757/./test_bpf_base.c
llvm compiling command template: $CLANG_EXEC -D__KERNEL__
-D__NR_CPUS__=$NR_CPUS -DLINUX_VERSION_CODE=$LINUX_VERSION_CODE
$CLANG_OPTIONS $KERNEL_INC_OPTIONS -Wno-unused-value -Wno-pointer-sign
-working-directory $WORKING_DIR -c "$CLANG_SOURCE" -target bpf -O2 -o -
libbpf: loading object './test_bpf_base.c' from buffer
libbpf: section .strtab, size 112, link 0, flags 0, type=3
libbpf: section .text, size 0, link 0, flags 6, type=1
libbpf: section .data, size 0, link 0, flags 3, type=1
...
libbpf: kernel version of ./test_bpf_base.c is 40300
libbpf: section .symtab, size 96, link 1, flags 0, type=2
bpf: config program 'func_write=vfs_write file->f_mode'
symbol:vfs_write file:(null) line:0 offset:0 return:0 lazy:(null)
parsing arg: file->f_mode into file, f_mode(1)
bpf: config 'func_write=vfs_write file->f_mode' is ok
If the error you pointed out is triggered, it should be:
libbpf: error: map handler doesn't belong to object ...
So we can always find which error message is belone to libbpf
and which is belone to perf.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH 04/16] bpf tools: Collect map definition in bpf_object Wang Nan <wangnan0@huawei.com> - 2015-11-24 14:50 +0100
Re: [PATCH 04/16] bpf tools: Collect map definition in bpf_object Arnaldo Carvalho de Melo <acme@kernel.org> - 2015-11-26 22:00 +0100
Re: [PATCH 04/16] bpf tools: Collect map definition in bpf_object "Wangnan (F)" <wangnan0@huawei.com> - 2015-11-27 07:20 +0100
Re: [PATCH 04/16] bpf tools: Collect map definition in bpf_object "Wangnan (F)" <wangnan0@huawei.com> - 2015-11-27 07:30 +0100
csiph-web