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"
next prev parent 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