From: "Theodore Ts'o" <tytso@mit.edu>
To: Alexei Starovoitov <ast@plumgrid.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: Checking to see if a bit is _not_ set in a ftrace event filter
Date: Tue, 2 Dec 2014 07:14:16 -0500 [thread overview]
Message-ID: <20141202121415.GA20127@thunk.org> (raw)
In-Reply-To: <CAMEtUuyyrUToWgczxdpj+SUEdr16NknQa_ZmWoGr8f261kyqmg@mail.gmail.com>
On Mon, Dec 01, 2014 at 09:58:32PM -0800, Alexei Starovoitov wrote:
> well, dwarf is only needed if you have > 6 function
> arguments in x64, since x64 ABI promotes scalars
> to 64-bit and passes first six args in registers, so it's
> trivial to know where arguments are even without debug info.
Well, if eBPF can get more information without DWARF, that's great.
I'll use whatever I can get, so long as I can do it without DWARF. :-)
So if eBPF can do a better job without the presence of debug info, and
even a better job with debug info (i.e., distro kernels where it's
worth the time to spend over an hour compiling a distro release rpm or
deb package), that would clearly be the best of both worlds. I
suspect that developers like me will want to continue to add
tracepoints so we can do what we need to get done w/o debug info,
though.
(To me that was always the reason why I ignored systemtap; it focused
too much on the need of the release customer --- which makes sense,
since nearly all of the stap developers worked for Red Hat --- but it
ignored the needs of kernel developers. So they shouldn't have been
surprised that most kernel developers returned the favor. :-)
> Similar situation is on most 64-bit risc archs.
> dwarf is needed when one wants to see a value of
> local C variable somewhere in the middle of the function,
> but it's not common and rarely works in practice, since
> var-tracking is not easy for compilers.
Yes; fortunately, we can make that available via adding new
tracepoints --- which in general is why I'm in favor of not relying on
the ability to grab information via pure kprobe and kretprobe. If we
can get the first six arguments on x86_64, then if I didn't think to
add a tracepoint, I can do some emergency debugging w/o needing to
recompile, which is a win. (But since I also do a lot of debug runs
using 32-bit kernels, it would be nice to have things that worked
there as well, which is why in general I'll add tracepoints once I
find that it might be useful to trace a particular function.)
Cheers,
- Ted
next prev parent reply other threads:[~2014-12-02 12:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-02 2:19 Checking to see if a bit is _not_ set in a ftrace event filter Theodore Ts'o
2014-12-02 2:41 ` Steven Rostedt
2014-12-02 3:52 ` Alexei Starovoitov
2014-12-02 3:57 ` Steven Rostedt
2014-12-02 3:58 ` Steven Rostedt
2014-12-02 4:51 ` Steven Rostedt
2014-12-02 5:04 ` Theodore Ts'o
2014-12-02 5:58 ` Alexei Starovoitov
2014-12-02 12:14 ` Theodore Ts'o [this message]
2014-12-03 0:02 ` Alexei Starovoitov
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=20141202121415.GA20127@thunk.org \
--to=tytso@mit.edu \
--cc=ast@plumgrid.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.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