public inbox for archer@sourceware.org
 help / color / mirror / Atom feed
From: Roland McGrath <roland@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: Project Archer <archer@sourceware.org>
Subject: Re: glibc with probes
Date: Sat, 05 Mar 2011 00:03:00 -0000	[thread overview]
Message-ID: <20110305000322.BBE09181F6E@magilla.sf.frob.com> (raw)
In-Reply-To: Tom Tromey's message of  Friday, 4 March 2011 11:56:30 -0700 <m3ei6mu335.fsf@fleche.redhat.com>

> Rayson's patch is still incomplete.  I don't recall offhand whether I
> thought it still needed an incompatible change, but it definitely can't
> be used in the situation we wanted it for.

If that's still so, I think it's news to Rayson.  There have been
numerous iterations of this code.  The current code is on the branch
roland/systemtap in the glibc.git repository.  If you have more probes
you want added, or changes you want made to the ones there now, please
tell rho@redhat.com and CC both the libc-alpha@sourceware.org and
systemtap@sourceware.org mailing lists.

> Roland> I've used this for some trivial manual tests of the
> Roland> setjmp/longjmp probes.
> 
> Sounds great, thanks.  We are pretty close to being able to test this in
> gdb as well.  Sergio is hard at work on the very last piece, namely
> parsing the probe arguments.

I plan to write tests for the setjmp/longjmp probes in the systemtap
suite shortly.  But aside from that, you will be the main user of it.
So please do try to test them and let me know if it works for you.  As I
recall, the only probe argument you wanted was the (demangled) PC where
longjmp returns to.  That's the third argument in the longjmp{,_target}
probes.  For your purposes, I don't think you care between longjmp and
longjmp_target.  The difference between them is in what the backtrace
from that point looks like (longjmp's caller or setjmp's caller).

For testing purposes, note that there are two or three instances of each
probe, and four (or six, depending how you count) ways to reach one of
them.  There are longjmp, _longjmp, and siglongjmp names you can use.
Then, when you compile with -D_FORTIFY_SOURCE=1 (or =2), you are getting
to a different internal entry code path when you use any of those names.
So for thorough testing, use all three flavors in the source code, and
compile that both with and without _FORTIFY_SOURCE.  (And, of course,
do all that for both 32-bit and 64-bit x86.)


Thanks,
Roland

  reply	other threads:[~2011-03-05  0:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-03 19:16 Roland McGrath
2011-03-04 18:56 ` Tom Tromey
2011-03-05  0:03   ` Roland McGrath [this message]
2011-03-07 15:18     ` Tom Tromey

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=20110305000322.BBE09181F6E@magilla.sf.frob.com \
    --to=roland@redhat.com \
    --cc=archer@sourceware.org \
    --cc=tromey@redhat.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).