Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Sergio Durigan Junior <sergiodj@redhat.com>
To: Pedro Alves <palves@redhat.com>
Cc: "Jose E. Marchesi" <jose.marchesi@oracle.com>,
	Doug Evans <dje@google.com>,
	       gdb-patches@sourceware.org
Subject: Re: [PATCH V2 3/9] New commands `enable probe' and `disable probe'.
Date: Fri, 17 Oct 2014 02:31:00 -0000	[thread overview]
Message-ID: <87iojjfmv6.fsf@redhat.com> (raw)
In-Reply-To: <54406623.2020802@redhat.com> (Pedro Alves's message of "Fri, 17	Oct 2014 01:43:15 +0100")

On Thursday, October 16 2014, Pedro Alves wrote:

> This also raises the question, can't we have both a stap
> probe and a dtrace probe with the name provider and name?  Like,
> using the proposed output that doesn't distinguish the probe types,
> can't the user end up with the confusing:
>
> Provider Name             Where              Semaphore Enabled Object
> demo     am-main          0x0000000000400c96           n/a     /home/jemarch/oracle/usdt/demo
> demo     am-main          0x0000000000400c8b n/a       always  /home/jemarch/oracle/usdt/demo
>
> Does GDB cope correctly with this?  Will the user have
> trouble specifying the probe he wants with the current UI?

Aha, a good question :-P.

Well, you can actually test this with current GDB, without even needing
dtrace:

  (gdb) info probes
  Provider Name Where              Semaphore Object                                                                    
  test    bla  0x00000000004004f4           a.out
  test    bla  0x00000000004004f5           a.out
  (gdb) b -p bla
  Breakpoint 1 at 0x4004f4 (2 locations)

You have basically two ways of specifying where the probe breakpoint is
going to be located: either by using -probe (or -p), or using
-probe-[type] (or -p[type]).  The second way is not problematic, because
you tell GDB that type you want explicitly, so there is no confusion.
However, in the first way, you put a breakpoint in a "probe" (the type
is not important here, only the probe name/provider).  GDB will then try
to see if any of the probe backends have probes with this name, and will
put a breakpoint on every probe it finds (again, no matter which type).

The logic for this is in gdb/probe.c:parse_probes, if you are
interested.

This is already working (as you can see in my example above), and Jose's
patch does not touch it, so we are pretty much covered in this area.

Nonetheless, I think it is a good idea to add one more field to the
output of 'info probes', specifying the probe type.

Thanks,

-- 
Sergio
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


  reply	other threads:[~2014-10-17  2:31 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-10 17:18 [PATCH V2 0/9] Add support for DTrace USDT probes to gdb Jose E. Marchesi
2014-10-10 17:18 ` [PATCH V2 3/9] New commands `enable probe' and `disable probe' Jose E. Marchesi
2014-10-10 18:15   ` Eli Zaretskii
2014-10-10 22:03   ` Doug Evans
2014-10-11  6:35     ` Jose E. Marchesi
2014-10-13 16:41       ` Doug Evans
2014-10-14 19:02         ` Sergio Durigan Junior
2014-10-17  0:07           ` Doug Evans
2014-10-17  0:36       ` Pedro Alves
2014-10-17  0:43         ` Pedro Alves
2014-10-17  2:31           ` Sergio Durigan Junior [this message]
2014-10-17 11:23             ` Pedro Alves
2014-10-17  0:55         ` Sergio Durigan Junior
2014-10-17  5:52           ` Jose E. Marchesi
2014-10-11 17:04     ` Sergio Durigan Junior
2014-10-14 18:53   ` Sergio Durigan Junior
2014-10-15 13:28     ` Jose E. Marchesi
2014-10-10 17:18 ` [PATCH V2 9/9] Announce the DTrace USDT probes support in NEWS Jose E. Marchesi
2014-10-10 18:16   ` Eli Zaretskii
2014-10-10 17:18 ` [PATCH V2 7/9] Simple testsuite for DTrace USDT probes Jose E. Marchesi
2014-10-16 22:36   ` Pedro Alves
2014-10-17 12:01     ` Jose E. Marchesi
2014-10-17 12:18       ` Pedro Alves
2014-10-10 17:18 ` [PATCH V2 1/9] Adapt `info probes' to support printing probes of different types Jose E. Marchesi
2014-10-10 17:18 ` [PATCH V2 5/9] New probe type: DTrace USDT probes Jose E. Marchesi
2014-10-14 19:01   ` Sergio Durigan Junior
2014-10-15 13:28     ` Jose E. Marchesi
2014-10-10 17:18 ` [PATCH V2 6/9] Support for DTrace USDT probes in x86_64 targets Jose E. Marchesi
2014-10-16 22:07   ` Pedro Alves
2014-10-17 12:35     ` Jose E. Marchesi
2014-10-17 12:42       ` Pedro Alves
2014-10-17 12:47         ` Jose E. Marchesi
2014-10-17 12:53           ` Pedro Alves
2014-10-17 19:48             ` Jose E. Marchesi
2014-10-16 22:07   ` Pedro Alves
2014-10-16 22:17   ` Pedro Alves
2014-10-10 17:18 ` [PATCH V2 2/9] Move `compute_probe_arg' and `compile_probe_arg' to probe.c Jose E. Marchesi
2014-10-10 17:18 ` [PATCH V2 4/9] New gdbarch functions: dtrace_parse_probe_argument, dtrace_probe_is_enabled, dtrace_enable_probe, dtrace_disable_probe Jose E. Marchesi
2014-10-10 17:18 ` [PATCH V2 8/9] Documentation for DTrace USDT probes Jose E. Marchesi
2014-10-10 18:18   ` Eli Zaretskii

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=87iojjfmv6.fsf@redhat.com \
    --to=sergiodj@redhat.com \
    --cc=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jose.marchesi@oracle.com \
    --cc=palves@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