From: Masami Hiramatsu <mhiramat@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Mark Wielaard <mark@klomp.org>,
Namhyung Kim <namhyung@kernel.org>,
Stephane Eranian <eranian@google.com>,
linux-toolchains@vger.kernel.org,
Arnaldo Carvalho de Melo <acme@kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
Ian Rogers <irogers@google.com>,
"Phillips, Kim" <kim.phillips@amd.com>,
Mark Rutland <mark.rutland@arm.com>,
Andi Kleen <andi@firstfloor.org>,
Masami Hiramatsu <mhiramat@kernel.org>
Subject: Re: Additional debug info to aid cacheline analysis
Date: Mon, 2 Nov 2020 17:27:12 +0900 [thread overview]
Message-ID: <20201102172712.0c9859124835089d80dc2348@kernel.org> (raw)
In-Reply-To: <20201030101004.GB2628@hirez.programming.kicks-ass.net>
Hi,
On Fri, 30 Oct 2020 11:10:04 +0100
Peter Zijlstra <peterz@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 <mark@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++
GCC only knows "a" is 0(%rsp), there is no other "assignments". Thus we need
to backtrace the %rax from the hit ip address until known assignment register
appears.
Note that if there is a loop, we have to trace it back too, but it's more hard,
func() {
struct yyy a;
int i;
...
for (i = 0; i < 100; i++)
a.b->c[i]++;
}
In this case, GCC will optimize "i" out and make an end-address.
(This is what GCC -O2 generated)
0000000000001190 <func>:
{
1190: f3 0f 1e fa endbr64
struct yyy a = *_a;
1194: 48 8b 57 10 mov 0x10(%rdi),%rdx
for (i = 0; i < 100; i++)
1198: 48 8d 42 08 lea 0x8(%rdx),%rax
119c: 48 81 c2 98 01 00 00 add $0x198,%rdx
11a3: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
a.b->c[i]++;
11a8: 83 00 01 addl $0x1,(%rax)
for (i = 0; i < 100; i++)
11ab: 48 83 c0 04 add $0x4,%rax
11af: 48 39 d0 cmp %rdx,%rax
11b2: 75 f4 jne 11a8 <func+0x18>
}
11b4: c3 retq
If we ignore the array support, this can be simplified as
1194: 48 8b 57 10 mov 0x10(%rdi),%rdx
1198: 48 8d 42 08 lea 0x8(%rdx),%rax
11a8: 83 00 01 addl $0x1,(%rax)
and maybe able to decode it.
Thank you,
> So what we want to (easily) find for that instruction is c::d.
>
> So given any instruction with a memop (either load or store) we want to
> find: type::member.
>
>
--
Masami Hiramatsu <mhiramat@kernel.org>
next prev parent reply other threads:[~2020-11-02 8:27 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-06 13:17 Additional debug info to aid cacheline analysis Peter Zijlstra
2020-10-06 19:00 ` Arnaldo Carvalho de Melo
2020-10-08 5:58 ` Stephane Eranian
2020-10-08 7:02 ` Peter Zijlstra
2020-10-08 9:32 ` Mark Wielaard
2020-10-08 21:23 ` Andi Kleen
2020-10-10 20:58 ` Mark Wielaard
2020-10-10 21:51 ` Mark Wielaard
[not found] ` <20201010220712.5352-1-mark@klomp.org>
2020-10-10 22:21 ` [PATCH] Only add -fno-var-tracking-assignments workaround for old GCC versions Ian Rogers
2020-10-12 18:59 ` Nick Desaulniers
2020-10-12 19:12 ` Mark Wielaard
2020-10-14 15:31 ` Sedat Dilek
2020-10-14 11:01 ` Mark Wielaard
2020-10-14 15:17 ` Andi Kleen
2020-10-17 12:01 ` [PATCH V2] " Mark Wielaard
2020-10-19 19:30 ` Nick Desaulniers
2020-10-20 15:27 ` Masahiro Yamada
2020-10-10 22:33 ` [PATCH] " Mark Wielaard
2020-10-11 11:04 ` Additional debug info to aid cacheline analysis Segher Boessenkool
2020-10-11 12:15 ` Florian Weimer
2020-10-11 12:23 ` Mark Wielaard
2020-10-11 12:28 ` Florian Weimer
2020-10-30 5:26 ` Namhyung Kim
2020-10-30 9:16 ` Mark Wielaard
2020-10-30 10:10 ` Peter Zijlstra
2020-11-02 8:27 ` Masami Hiramatsu [this message]
2020-11-03 4:22 ` Namhyung Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201102172712.0c9859124835089d80dc2348@kernel.org \
--to=mhiramat@kernel.org \
--cc=acme@kernel.org \
--cc=andi@firstfloor.org \
--cc=eranian@google.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kim.phillips@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-toolchains@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mark@klomp.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).