linux-trace-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: ahmadkhorrami <ahmadkhorrami@ut.ac.ir>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	linux-trace-users <linux-trace-users@vger.kernel.org>,
	lttng-dev <lttng-dev@lists.lttng.org>,
	Jeremie Galarneau <jeremie.galarneau@efficios.com>,
	Namhyung Kim <namhyung@kernel.org>,
	linux-trace-users-owner@vger.kernel.org
Subject: Re: Capturing User-Level Function Calls/Returns
Date: Wed, 15 Jul 2020 17:48:58 -0400	[thread overview]
Message-ID: <20200715174858.4698803c@oasis.local.home> (raw)
In-Reply-To: <98de6fe15a816d8f06ba3d5df0f10540@ut.ac.ir>

On Thu, 16 Jul 2020 02:09:50 +0430
ahmadkhorrami <ahmadkhorrami@ut.ac.ir> wrote:

> Hi Steven and Mathieu,
> Firstly, many thanks! This method seems to be the most efficient method. 
> But, IIUC, what you suggest requires source code compilation. I need an 
> efficient dynamic method that, given the function address, captures its 
> occurrence and stores some information from the execution context. Is 
> there anything better than Uprobes perhaps with no trap into the kernel? 
> Why do we need traps?
> Regards.

Without recompiling, how would that be implemented?

You would need to insert a jump on top of code, and still be able to
preserve that code. What a trap does, is to insert a int3, that will
trap into the kernel, it would then emulate the code that the int3 was
on, and also call some code that can trace the current state.

To do it in user land, you would need to find way to replace the code
at the location you want to trace, with a jump to the tracing
infrastructure, that will also be able to emulate the code that the
jump was inserted on top of. As on x86, that jump will need to be 5
bytes long (covering 5 bytes of text to emulate), where as a int3 is a
single byte.

Thus, you either recompile and insert nops where you want to place your
jumps, or you trap using int3 that can do the work from within the
kernel.

-- Steve

  reply	other threads:[~2020-07-15 21:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-15 16:07 Capturing User-Level Function Calls/Returns ahmadkhorrami
2020-07-15 18:28 ` Steven Rostedt
2020-07-15 18:45   ` Mathieu Desnoyers
2020-07-15 21:39     ` ahmadkhorrami
2020-07-15 21:48       ` Steven Rostedt [this message]
2020-07-15 22:25         ` ahmadkhorrami
2020-07-16  1:06         ` [lttng-dev] " Michel Dagenais
2020-07-16  1:49           ` Frank Ch. Eigler
2020-07-16 16:26             ` ahmadkhorrami
2020-07-16 16:20           ` ahmadkhorrami
2020-07-16 16:34           ` ahmadkhorrami
2020-07-16  1:04   ` Namhyung Kim
2020-07-16 16:07     ` ahmadkhorrami

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=20200715174858.4698803c@oasis.local.home \
    --to=rostedt@goodmis.org \
    --cc=ahmadkhorrami@ut.ac.ir \
    --cc=jeremie.galarneau@efficios.com \
    --cc=linux-trace-users-owner@vger.kernel.org \
    --cc=linux-trace-users@vger.kernel.org \
    --cc=lttng-dev@lists.lttng.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=namhyung@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;
as well as URLs for NNTP newsgroup(s).