public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@redhat.com>
To: Wilco Dijkstra <Wilco.Dijkstra@arm.com>,
	"libc-alpha@sourceware.org" <libc-alpha@sourceware.org>
Cc: nd <nd@arm.com>
Subject: Re: Are LIBC probes part of the ABI?
Date: Fri, 23 Mar 2018 19:01:00 -0000	[thread overview]
Message-ID: <f80483a1-1861-b71d-caee-2715fc71f365@redhat.com> (raw)
In-Reply-To: <DB6PR0801MB2053CC516FF8314ADD86AEC983D40@DB6PR0801MB2053.eurprd08.prod.outlook.com>

On 03/19/2018 10:40 AM, Wilco Dijkstra wrote:
> Hi,
> 
> Various patches have recently removed LIBC probes. I couldn't find a script
> or similar that lists these in the binary. Are probes created dynamically and
> therefore removing a probe is no different from not executing one?
> 
> Some malloc improvements were backported in November. This included
> removal of a few probes, so I think the answer is yes, but I'd like to be sure.

(1) How do you list probes?

You can use systemtap to list the "mark" (probe) points.

https://sourceware.org/systemtap/langref/Probe_points.html#SECTION00055800000000000000

stap -L 'process("/lib64/libc.so.6").mark("*")'
stap -L 'process("/lib64/ld-linux-x86-64.so.2").mark("*")'

(2) Are probes created dynamically?

The instrumentation is indeed dynamic, it uses the kernel kprobes/uprobes infrastructure.

The probe is nop space in the binary with additional markup in .note.stapsdt section, but
it also impacts how the compiler is allowed to manipulate arguments passed to the probe
since they have to be available for the probe to access them.

(3) Is removing a probe no different from executing it?

Yes and no. Removing the probe means it is no longer in the list of known probes, and
therefore slightly different from the probe not executing. Semantically though from the
perspective of a running trace script it will appear as if the probe is never triggered
because it doesn't exist.

(4) Is a probe part of the ABI?

stap probes are *not* part of the ABI.

Please see:

https://www.gnu.org/software/libc/manual/html_node/Internal-Probes.html#Internal-Probes

~~~
These probes are not part of the GNU C Library stable ABI, and they are subject to change or removal across releases. Our only promise with regard to them is that, if we find a need to remove or modify the arguments of a probe, the modified probe will have a different name, so that program monitors relying on the old probe will not get unexpected arguments. 
~~~

In practice the loader probes are very important to gdb's scalable DSO scanning.

(5) New and removed probes should be documented!

See the manual/probes.texi. We should maintain an accurate list of probes.

Does that answer your question?

-- 
Cheers,
Carlos.

      reply	other threads:[~2018-03-23 19:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-19 15:40 Wilco Dijkstra
2018-03-23 19:01 ` Carlos O'Donell [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=f80483a1-1861-b71d-caee-2715fc71f365@redhat.com \
    --to=carlos@redhat.com \
    --cc=Wilco.Dijkstra@arm.com \
    --cc=libc-alpha@sourceware.org \
    --cc=nd@arm.com \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).