Re: [PATCH 11/20 v2] tracing: Add symbol type to function based events

From: Arnaldo Carvalho de Melo
Date: Thu Feb 08 2018 - 11:23:01 EST


Em Thu, Feb 08, 2018 at 10:59:00AM -0500, Steven Rostedt escreveu:
> On Thu, 8 Feb 2018 12:20:31 +0100
> Jiri Olsa <jolsa@xxxxxxxxxx> wrote:
>
> > > +Symbols (function names)
> > > +========================
> > > +
> > > +To display kallsyms "%pS" type of output, use the special type "symbol".
> > > +
> > > +Again, using gdb to find the offset of the "func" field of struct work_struct
> > > +
> > > +(gdb) printf "%d\n", &((struct work_struct *)0)->func
> > > +24
> >
> > you could also use Arnaldo's pahole for this, seems like less typing:
> >
> > $ pahole ./vmlinux -C work_struct
> > die__process_function: tag not supported (INVALID)!
> > struct work_struct {
> > atomic_long_t data; /* 0 8 */
> > struct list_head entry; /* 8 16 */
> > work_func_t func; /* 24 8 */
> >
> > it's in 'dwarves' package
>
> Nice, I'll have to document that:
>
> $ pahole ./vmlinux -C net_device |grep perm
> unsigned char perm_addr[32]; /* 558 32 */

You can also use just one .o file to speed things up instead of using
vmlinux, where it ill go on parsing stuff till it finds a .o with that
struct definition, i.e.:

[acme@jouet linux]$ pahole -C work_struct ../build/v4.15.0-rc9+/kernel/sys.o
struct work_struct {
atomic_long_t data; /* 0 8 */
struct list_head entry; /* 8 16 */
work_func_t func; /* 24 8 */

/* size: 32, cachelines: 1, members: 3 */
/* last cacheline: 32 bytes */
};

One may prefer hexadecimal numbers:

[acme@jouet linux]$ pahole --hex -C work_struct ../build/v4.15.0-rc9+/kernel/sys.o
struct work_struct {
atomic_long_t data; /* 0 0x8 */
struct list_head entry; /* 0x8 0x10 */
work_func_t func; /* 0x18 0x8 */

/* size: 32, cachelines: 1, members: 3 */
/* last cacheline: 32 bytes */
};
[acme@jouet linux]$

Or even expand everything and get offsets from that work_struct to
inside the list_head or other embedded types:

[acme@jouet linux]$ pahole -E --hex -C work_struct ../build/v4.15.0-rc9+/kernel/sys.o
struct work_struct {
/* typedef atomic_long_t -> atomic64_t */ struct {
long int counter; /* 0 0x8 */
} data; /* 0 0x8 */
struct list_head {
struct list_head * next; /* 0x8 0x8 */
struct list_head * prev; /* 0x10 0x8 */
} entry; /* 0x8 0x10 */
/* typedef work_func_t */ void (*func)(struct work_struct *); /* 0x18 0x8 */

/* size: 32, cachelines: 1, members: 3 */
/* last cacheline: 32 bytes */
};
[acme@jouet linux]$

A long time ago I put the expansion of task_struct somewhere... yeah,
almost a decade ago, 2008, but it was not -E, was -p (i.e. expand
pointer types):

http://vger.kernel.org/~acme/vmlinux-expand_pointers-task_struct.txt

/* size: 1680, cachelines: 27, members: 141 */
/* sum members: 1641, holes: 10, sum holes: 39 */
/* bit holes: 1, sum bit holes: 31 bits */
/* paddings: 1, sum paddings: 4 */
/* last cacheline: 16 bytes */
};

Anyway, now we have:

[acme@jouet linux]$ pahole -C task_struct ../build/v4.15.0-rc9+/kernel/sys.o | tail -6
struct thread_struct thread; /* 6592 4352 */

/* size: 10944, cachelines: 171, members: 4 */
/* sum members: 10896, holes: 1, sum holes: 48 */
/* paddings: 1, sum paddings: 48 */
};
[acme@jouet linux]$

We have way more memory and features now :-)

The number of members is because now we have that randomize_struct stuff
that creates an unamed struct inside task_struct, so we have:

struct task_struct {
struct thread_info thread_info; /* 0 8 */
volatile long int state; /* 8 8 */

/* XXX 48 bytes hole, try to pack */

/* --- cacheline 1 boundary (64 bytes) --- */
struct {
void * stack; /* 64 8 */
atomic_t usage; /* 72 4 */
<SNIP>
int pagefault_disabled; /* 6504 4 */

/* XXX 4 bytes hole, try to pack */

struct task_struct * oom_reaper_list; /* 6512 8 */
struct vm_struct * stack_vm_area; /* 6520 8 */
/* --- cacheline 102 boundary (6528 bytes) --- */
atomic_t stack_refcount; /* 6528 4 */

/* XXX 4 bytes hole, try to pack */

void * security; /* 6536 8 */
}; /* 64 6528 */

/* XXX last struct has 48 bytes of padding */

/* --- cacheline 103 boundary (6592 bytes) --- */
struct thread_struct thread; /* 6592 4352 */

/* size: 10944, cachelines: 171, members: 4 */
/* sum members: 10896, holes: 1, sum holes: 48 */
/* paddings: 1, sum paddings: 48 */
};

So indeed, 'just' 4 members.

I guess I'll have to add some new mode where one can ask for unnamed
structs to be removed for the sake of --reorganize and the summary
information at the end, erm...

Anyway, digressed too much :-)

- Arnaldo