This patch introduces BPF Type Format (BTF).
BTF (BPF Type Format) is the meta data format which describes
the data types of BPF program/map. Hence, it basically focus
on the C programming language which the modern BPF is primary
using. The first use case is to provide a generic pretty print
capability for a BPF map.
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To help with using just that object file, avoiding processing big files
such as vmlinux, e.g.:
$ pahole -I vmlinux
<SNIP>
/* Used at: /home/acme/git/perf/init/main.c */
/* <1f4a5> /home/acme/git/perf/arch/x86/include/asm/orc_types.h:85 */
struct orc_entry {
s16 sp_offset; /* 0 2 */
s16 bp_offset; /* 2 2 */
unsigned int sp_reg:4; /* 4:28 4 */
unsigned int bp_reg:4; /* 4:24 4 */
unsigned int type:2; /* 4:22 4 */
/* size: 6, cachelines: 1, members: 5 */
/* padding: 65534 */
/* bit_padding: 22 bits */
/* last cacheline: 6 bytes */
/* BRAIN FART ALERT! 6 != 8 + 0(holes), diff = -2 */
};
<SNIP>
So I noticed that BFA, need to work on it, to make the testing process
faster, better not process vmlinux.o, instead, do:
$ pahole -C orc_entry ${kernel_build_dir}/init/main.o
Much faster, as main.o is much smaller than the vmlinux file.
Now to fix the processing of 'struct orc_entry'.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
If we processed at least one file we should return 0 to mean success.
Fixes: 02a456f5f5 ("pahole: Search and use running kernel vmlinux when no file is passed")
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Seems like a nice shortcut for kernel hackers, and one that makes sure
the right vmlinux file is used, as it reads the running kernel build id
from /sys/kernel/notes and then searches the well known path for vmlinux
files:
vmlinux
/boot/vmlinux
/boot/vmlinux-4.14.0+
/usr/lib/debug/boot/vmlinux-`uname -r`
/lib/modules/`uname -r`/build/vmlinux
/usr/lib/debug/lib/modules/`uname -r`/vmlinux
/usr/lib/debug/boot/vmlinux-`uname -r`.debug
To find one with a matching build id (.notes ELF section, then
nhdr->n_type == NT_GNU_BUILD_ID), just like the Linux kernel 'perf
tools', where this code comes from, with some minor modifications to
cope with not having symbol_conf, symfs, etc.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Flavio needed this and found it only after some head scratching, add it.
Someone could help here by looking at other missing entries in the man
page, getting it in synch with 'pahole --help' ;-)
Reported-by: Flavio Leitner <fbl@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The ghostprotocols.net domain is busted for a while, point to the
more permanent OLS proceedings pdf hosted at kernel.org.
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Take 'struct task_struct' in the Linux kernel, these fields:
/* --- cacheline 2 boundary (128 bytes) --- */
struct sched_entity se; /* 128 448 */
/* XXX last struct has 24 bytes of padding */
/* --- cacheline 9 boundary (576 bytes) --- */
struct sched_rt_entity rt; /* 576 48 */
The sched_entity struct has 24 bytes of padding, and that info would
only appear when printing 'struct task_struct' if class__find_holes()
had previously been run on 'struct sched_entity' which wasn't always the
case, make sure that happens.
This results in this extra stat being printed for 'struct task_struct':
/* paddings: 4, sum paddings: 38 */
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
A diff for 'pahole -EC task_struct vmlinux' should clarify what this fixes:
[acme@jouet linux]$ diff -u /tmp/before.c /tmp/after.c | head -30
--- /tmp/before.c 2016-06-29 17:00:38.082647281 -0300
+++ /tmp/a.c 2016-06-29 17:03:36.913124779 -0300
@@ -43,8 +43,8 @@
struct list_head * prev; /* 176 8 */
} group_node; /* 168 16 */
unsigned int on_rq; /* 184 4 */
+ /* --- cacheline 3 boundary (192 bytes) --- */
/* typedef u64 */ long long unsigned int exec_start; /* 192 8 */
- /* --- cacheline 1 boundary (64 bytes) was 4 bytes ago --- */
/* typedef u64 */ long long unsigned int sum_exec_runtime; /* 200 8 */
/* typedef u64 */ long long unsigned int vruntime; /* 208 8 */
/* typedef u64 */ long long unsigned int prev_sum_exec_runtime; /* 216 8 */
@@ -53,40 +53,40 @@
/* typedef u64 */ long long unsigned int wait_start; /* 232 8 */
/* typedef u64 */ long long unsigned int wait_max; /* 240 8 */
/* typedef u64 */ long long unsigned int wait_count; /* 248 8 */
+ /* --- cacheline 4 boundary (256 bytes) --- */
/* typedef u64 */ long long unsigned int wait_sum; /* 256 8 */
/* typedef u64 */ long long unsigned int iowait_count; /* 264 8 */
/* typedef u64 */ long long unsigned int iowait_sum; /* 272 8 */
/* typedef u64 */ long long unsigned int sleep_start; /* 280 8 */
/* typedef u64 */ long long unsigned int sleep_max; /* 288 8 */
- /* --- cacheline 1 boundary (64 bytes) --- */
/* typedef s64 */ long long int sum_sleep_runtime; /* 296 8 */
/* typedef u64 */ long long unsigned int block_start; /* 304 8 */
/* typedef u64 */ long long unsigned int block_max; /* 312 8 */
+ /* --- cacheline 5 boundary (320 bytes) --- */
/* typedef u64 */ long long unsigned int exec_max; /* 320 8 */
/* typedef u64 */ long long unsigned int slice_max; /* 328 8 */
/* typedef u64 */ long long unsigned int nr_migrations_cold; /* 336 8 */
[acme@jouet linux]$
I.e. the boundary detection was being reset at each expanded struct, do the math globally,
using the member offset, that was already done globally and correctly.
Reported-and-Tested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
That conf_fprintf can be elided as it is always NULL for the root call,
i.e. only when expanding types is that it will be called recursively.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
We need to get it under some ifdefs to avoid breaking the build in
distros where these tags are not defined.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This causes a segfault:
at /home/teuf/freesoftware/pahole/dwarf_loader.c:141
at /home/teuf/freesoftware/pahole/dwarf_loader.c:170
cu=0x66bc70) at /home/teuf/freesoftware/pahole/dwarf_loader.c:1535
at /home/teuf/freesoftware/pahole/dwarf_loader.c:1552
fn=0x7ffff79cd160 <__FUNCTION__.8133> "die__process_class")
at /home/teuf/freesoftware/pahole/dwarf_loader.c:1593
at /home/teuf/freesoftware/pahole/dwarf_loader.c:1288
We're not supposed to hash those unsupported tags, so just check for it and
avoid hashing.
Reported-by: Christophe Fergeau <cfergeau@redhat.com>
Cc: Dodji Seketeli <dodji@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Still need to check what to fprintf for this, but at least have it in
the type lists so that we can find it.
Reported-by: Christophe Fergeau <cfergeau@redhat.com>
Cc: Dodji Seketeli <dodji@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
No tool in this suite has any use for that, so just leave the comments
and pointers to the documentation for these tags and stop bothering the
user.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Need to read more on http://www.artima.com/cppsource/rvalue.html, but
handling it mostly like DW_TAG_typedef so that at least references to it
are resolved, we can get its byte size, etc.
FIXME: look at the vtable parameters, some are resolving to "(null)".
Reported-by: Benjamin Kosnik <bkoz@redhat.com>
Reported-by: Mark Wieelard <mjw@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=962571
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
$ cat foo
cat: foo: No such file or directory
Before:
$ pahole foo
pahole: No debugging information found
After:
$ pahole foo
pahole: foo: No such file or directory
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Before it would print no message, only update its exit status, now:
$ cat foo
cat: foo: No such file or directory
$ pdwtags foo
pdwtags: foo: No such file or directory
$ pdwtags /dev/null
ctf__new: cannot get elf header.
pdwtags: /dev/null: Invalid argument
$
Reported-by: Eric Blake <eblake@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=949034
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Silly bug, it was trying to return a negative index stating what file
had problems in the provided array, but if the first had problems it was
return -0, duh, fix it by returning the first as 1, etc.
With this, calling 'pdwtags non-existent-file' would return no errors
via $?.
Next csets will provide proper error messages, using what is in errno
and this index to tell what file has problems.
Reported-by: Eric Blake <eblake@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=949034
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To deal with unrepresentable constant logarithms we end up causing a
build error, provide the declaration so that the compiler shut up.
Taken, as the other related code, from the Linux kernel sources.
For reference, the warning:
[ 40%] Building C object CMakeFiles/dwarves_reorganize.dir/dwarves_reorganize.o
/home/acme/git/pahole/dwarves_reorganize.c: In function ‘class__demote_bitfields’:
/home/acme/git/pahole/dwarves_reorganize.c:536:168: warning: implicit declaration of function ‘____ilog2_NaN’ [-Wimplicit-function-declaration]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The current release is v1.10, but CMakeLists.txt had just v1.9, fix it.
Reported-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
In class_member__dwarf_recode_bitfield, making it more robust, as
now we're in the process of supporting DW_TAG_partial_unit, where
some types seem to be in some ther unit and thus not being found
at the moment.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
It just about having a location expression that is referenced by other
tags to save space, since we don't have use for loc exprs so far, just
ignore it instead of spamming the user with "tag not supported"
warnings.
First seen on binaries generated by gcc 4.9
Reported-by: Diego Elio Pettenò <flameeyes@flameeyes.eu>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
DW_TAG_mutable_type was a mistake in an early DWARFv3 draft and was
removed in the final version.
http://dwarfstd.org/ShowIssue.php?issue=050223.1
Signed-off-by: Mark Wielaard <mjw@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
obstack_alloc was used in __tag__alloc to allocate tag object. As the
result some fields of the tag object are not initialized.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
As Thomas Gleixner wisely pointed out, using 'self' is stoopid, it
doesn't convey useful information, so use sensible names
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The changeset:
commit f043528
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Sun Aug 16 12:26:33 2009 -0300
dwarves_reorganize: Fix class__demote_bitfields, we need power of
two bytes
Had a correct changeset description, but an incorrect implementation, it
was not rouding up to the next power of two, but to the next multiple of
2, i.e. when a bitfield has 2 bits, it was deciding it needed 2 bytes,
not 1.
Fix it by copying the roundup_power_of_two code from the Linux kernel,
mostly by David Howells <dhowells@redhat.com>.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When computing the size of a class, leave, caused problems in
some cases, links to the reports are in the comments.
Reported-by: Nicolas <nikos42@gmail.com>
Suggested-by: Mark Wielaard <mjw@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
As Thomas Gleixner wisely pointed out, using 'self' is stupid, it
doesn't convey useful information, so use sensible names.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
After emitting a warning that a tag is not supported __die__process_tag
was returning NULL, making die__process_unit think that the problem
was insufficient memory.
Introduce a global variable 'unsupported_tag' and return it instead,
that way die__process_unit can distinguish ENOMEM from unsupported tags.
Reported-by: Thiago Macieira <thiago.macieira@intel.com>
Tested-by: Thiago Macieira <thiago.macieira@intel.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Martin KaFai Lau
Arnaldo Carvalho de Melo
Mark Wielaard
Masatake YAMATO
Cody P Schafer