[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190716142005.GE3402@hirez.programming.kicks-ass.net>
Date: Tue, 16 Jul 2019 16:20:05 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Changbin Du <changbin.du@...il.com>
Cc: Will Deacon <will@...nel.org>, rostedt@...dmis.org,
mingo@...hat.com, corbet@....net, linux@...linux.org.uk,
catalin.marinas@....com, tglx@...utronix.de, bp@...en8.de,
hpa@...or.com, x86@...nel.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] tracing/fgraph: support recording function return values
On Tue, Jul 16, 2019 at 10:08:18PM +0800, Changbin Du wrote:
> On Mon, Jul 15, 2019 at 12:12:31PM +0200, Peter Zijlstra wrote:
> > Alternatively, we can have recordmcount (or objtool) mark all functions
> > with a return value when the build has DEBUG_INFO on. The dwarves know
> > the function signature.
> >
> We can extend the recordmcount tool to search 'subprogram' tag in the DIE tree.
> In below example, the 'DW_AT_type' is the type of function pidfd_create().
>
> $ readelf -w kernel/pid.o
> [...]
> <1><1b914>: Abbrev Number: 232 (DW_TAG_subprogram)
> <1b916> DW_AT_name : (indirect string, offset: 0x415e): pidfd_create
> <1b91a> DW_AT_decl_file : 1
> <1b91b> DW_AT_decl_line : 471
> <1b91d> DW_AT_decl_column : 12
> <1b91e> DW_AT_prototyped : 1
> <1b91e> DW_AT_type : <0xcc>
> <1b922> DW_AT_low_pc : 0x450
> <1b92a> DW_AT_high_pc : 0x50
> <1b932> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
> <1b934> DW_AT_GNU_all_call_sites: 1
> <1b934> DW_AT_sibling : <0x1b9d9>
> [...]
>
> To that end, we need to introduce libdw library for recordmcount. I will have a
> try this week.
Right; but only when this config option is set.
> And probably, we can also record the parameters?
The 'fun' part is where to store all this information in the kernel and
how fast you can find it while tracing.
Powered by blists - more mailing lists