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 -- To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html