Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Yao Qi <yao@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Add breakpoint_created observer to update tracepoint_count.
Date: Fri, 09 Nov 2012 02:28:00 -0000	[thread overview]
Message-ID: <509C6A51.4090707@redhat.com> (raw)
In-Reply-To: <509C57B2.5020806@codesourcery.com>

On 11/09/2012 01:09 AM, Yao Qi wrote:
> On 11/08/2012 02:13 AM, Pedro Alves wrote:
>> > No need to install an observer for a notification that is emitted in the same
>> > module the new observer is in.  This is internals of the breakpoints module.
>> > All set_breakpoint_count's calls are centralized in install_breakpoint, through
>> > set_breakpoint_number.  All but break-range's, that is.  I don't recall why
>> > that doesn't use install_breakpoint.  Maybe it should.
>> > 
> My original thought is to move tracepoint-related code from
> breakpoint.c to tracepoint.c, so register a breakpoint_created observer
> in tracepoint.c to update 'tracepoint_count'.  Unfortunately,
> tracepoint commands use some breakpoint internal macros that prevent
> moving them to tracepoint.c, so I move the observer register code back
> to breakpoint.c.

I see.

> 
> Yes, it is not necessary to register a observer to update some state in
> the same module.
> 
>> > We should be able to put 'if (is_tracepoint) set_tracepoint_count()' in
>> > install_breakpoint too.
> Hmmm, that sounds the right place to update 'tracepoint_count'.  How
> about patch below?  A new test is added, without this fix, this test
> fails.

Looks good.  Further comments below.

> 2012-11-09  Yao Qi  <yao@codesourcery.com>
>
> 	* gdb.mi/mi-break.exp (test_abreak_creation): New.

I suggest:

 	* gdb.mi/mi-break.exp (test_abreak_creation): New procedure.
	(top level): Call it.

And here ...

> +proc test_abreak_creation {} {
> +    mi_gdb_test "522-break-insert -a main" \
> +	"522\\^done,bkpt=\{number=\"10\",type=\"tracepoint\".*\"\}" \
> +	"break-insert -a operation"
> +
> +    mi_gdb_test "p \$tpnum" ".* = 10.*" "print \$tpnum"
> +}
> +

... I suggest checking tpnum before creating the tracepoint too

BTW, do we need "10.*", or is "10" good enough?  "10.*" matches 100
or other bogus numbers too.  And usually ".*" at the start of the
regex is not necessary.

So all in all (untested):

    mi_gdb_test "p \$tpnum" " = void" "\$tpnum before tracepoint"

    mi_gdb_test "522-break-insert -a main" \
	"522\\^done,bkpt=\{number=\"10\",type=\"tracepoint\".*\"\}" \
	"break-insert -a operation"

    mi_gdb_test "p \$tpnum" " = 10" "\$tpnum after tracepoint"


  reply	other threads:[~2012-11-09  2:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-07  0:50 Yao Qi
2012-11-07 18:13 ` Pedro Alves
2012-11-09  1:09   ` Yao Qi
2012-11-09  2:28     ` Pedro Alves [this message]
2012-11-09  7:26       ` Yao Qi
2012-11-09  9:54         ` Pedro Alves

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=509C6A51.4090707@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=yao@codesourcery.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