Hi Masami, On Mon, Nov 2, 2020 at 5:27 PM Masami Hiramatsu <mhira...@kernel.org> wrote: > > Hi, > > On Fri, 30 Oct 2020 11:10:04 +0100 > Peter Zijlstra <pet...@infradead.org> wrote: > > > On Fri, Oct 30, 2020 at 10:16:49AM +0100, Mark Wielaard wrote: > > > Hi Namhyung, > > > > > > On Fri, Oct 30, 2020 at 02:26:19PM +0900, Namhyung Kim wrote: > > > > On Thu, Oct 8, 2020 at 6:38 PM Mark Wielaard <m...@klomp.org> wrote: > > > > > GCC using -fvar-tracking and -fvar-tracking-assignments is pretty good > > > > > at keeping track of where variables are held (in memory or registers) > > > > > when in the program, even through various optimizations. > > > > > > > > > > -fvar-tracking-assignments is the default with -g -O2. > > > > > Except for the upstream linux kernel code. Most distros enable it > > > > > again, but you do want to enable it by hand when building from the > > > > > upstream linux git repo. > > > > > > > > Please correct me if I'm wrong. This seems to track local variables. > > > > But I'm not sure it's enough for this purpose as we want to know > > > > types of any memory references (not directly from a variable). > > > > > > > > Let's say we have a variable like below: > > > > > > > > struct xxx a; > > > > > > > > a.b->c->d++; > > > > > > > > And we have a sample where 'd' is updated, then how can we know > > > > it's from the variable 'a'? Maybe we don't need to know it, but we > > > > should know it accesses the 'd' field in the struct 'c'. > > > > > > > > Probably we can analyze the asm code and figure out it's from 'a' > > > > and accessing 'd' at the moment. I'm curious if there's a way in > > > > the DWARF to help this kind of work. > > > > > > DWARF does have that information, but it stores it in a way that is > > > kind of opposite to how you want to access it. Given a variable and an > > > address, you can easily get the location where that variable is > > > stored. But if you want to map back from a given (memory) location and > > > address to the variable, that is more work. > > > > The principal idea in this thread doesn't care about the address of the > > variables. The idea was to get the data type and member information from > > the instruction. > > > > So in the above example: a.b->c->d++; what we'll end up with is > > something like: > > > > inc 8(%rax) > > > > Where %rax contains c, and the offset of d in c is 8. > > For this simple case, it is possible. > > This offset information is stored in the DWARF as a data-structure type > information. (perf-probe uses it to find how to get the given local var's > fields) > > So if we do this off-line, I think it is possible if it is recorded with > instruction-pointers. For each place, we can do > > - decode instruction and get the access address. > - get var assignment of %rax at that IP. > - get type information of var and find the field from offset. > > However, the problem is that if the DWARF has only assignment of "a", > we need to decode the function body. (and usually this happens) > > func() { > struct xxx a; > ... > a.b->c->d++; > } > > In this case, only "a" is the local variable. So DWARF records assignment of > "a", not "b" nor "c" (since those are not a name of variables, just a name > of fields). GCC may generate something like > > mov 16(%rsp),%rdx // rdx = a.b > mov 8(%rdx),%rax // rax = b->c > inc 8(%rax) // c->d++
Right, it'd be really nice if compiler can add information about the (hidden) assignments in the rdx and rax here. Thanks Namhyung