public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Alexei Starovoitov <ast@plumgrid.com>
Cc: linux-kernel@vger.kernel.org,
	"zhangwei(Jovi)" <jovi.zhangwei@huawei.com>
Subject: LTTng-UST bytecode interpreter
Date: Sat, 18 Oct 2014 10:33:56 +0000 (UTC)	[thread overview]
Message-ID: <495423996.11122.1413628436227.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <1895341174.11073.1413626706382.JavaMail.zimbra@efficios.com>

Hi Alexei,

Following our Plumbers discussion, here are links to
lttng-ust and lttng-tools parts that are relevant to
the bytecode I use for tracepoint filtering:

http://git.lttng.org/?p=lttng-tools.git;a=summary
src/lib/lttng-ctl/filter/*.[ch]
  -> parser of filter expressions to AST, then to
     intermediate representation, followed by
     bytecode generation.

The bytecode is then moved from the client to the
application being traced through the lttng-sessiond
daemon.

http://git.lttng.org/?p=lttng-ust.git;a=summary
liblttng-ust/lttng-filter.c:
  filter "linker" attaching bytecode to tracepoint.
  _lttng_filter_event_link_bytecode() has all the
  steps required to translate a bytecode into
  something the interpreter can use.

liblttng-ust/lttng-filter-specialize.c:
  Perform type specialization of some opcodes. This
  is done after linking to an event fields, now that
  we know their type.

liblttng-ust/lttng-filter-validator.c
  Validation of the bytecode: making sure typing is
  consistent, checks there are no loops (no backward
  jump).

liblttng-ust/lttng-filter-interpreter.c
  Bytecode interpreter, executes quickly without any
  checks, relying on the fact that they were already
  performed by the validator. It is a threaded
  interpreter which has 2 registers aliasing the top
  of its stack.

My general approach is to use an interpreter to deal
with the general case, which makes porting to new
architectures easy. We can then have JIT phases if
we want to eventually translate this bytecode into
native instruction.

Working with a bytecode which has a slightly higher
level semantic allows dealing with strings as a basic
type in addition to integers and floating point values.

Please note that the current bytecode is limited to
64-bit integers. We can eventually extend it to be
more compact (8, 16, 32-bit integers).

This is just provided as input in case some ideas
can be useful for your work on eBPF. 

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

      parent reply	other threads:[~2014-10-18 10:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1895341174.11073.1413626706382.JavaMail.zimbra@efficios.com>
2014-10-18 10:31 ` LTTng-UST bytecode interpreter Mathieu Desnoyers
2014-10-18 10:33 ` Mathieu Desnoyers [this message]

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=495423996.11122.1413628436227.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=ast@plumgrid.com \
    --cc=jovi.zhangwei@huawei.com \
    --cc=linux-kernel@vger.kernel.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