From: Tom Tromey <tromey@redhat.com>
To: luis_gustavo@mentor.com
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC stub-side break conditions 3/5] GDB-side changes
Date: Fri, 06 Jan 2012 21:44:00 -0000 [thread overview]
Message-ID: <m3aa601p6q.fsf@fleche.redhat.com> (raw)
In-Reply-To: <4F05BA10.3090107@mentor.com> (Luis Machado's message of "Thu, 05 Jan 2012 12:56:16 -0200")
>>>>> "Luis" == Luis Machado <luis_gustavo@mentor.com> writes:
Luis> This patch handles GDB-specific changes to support stub-side
Luis> breakpoint conditions.
Nice series, I quite like it.
Luis> I ran the testsuite and had no additional failures.
I think the patches should include some tests for the new feature.
Luis> I'd like to hear about the change to "info break" and also the way we
Luis> should pass conditions down to the stub.
I looked at this code and, while I think the output bits are fine, there
is something I don't understand:
+ /* Print whether the remote stub is doing the breakpoint's condition
+ evaluation. If GDB is doing the evaluation, don't print anything. */
+ if (loc && is_breakpoint (b) && loc->cond_bytecode
+ && breakpoint_condition_evaluation_mode ()
+ != condition_evaluation_gdb)
(First, there should be parens around that last subexpression.)
If the user changes 'condition-evaluation', then the new setting might
affect what "info break" prints. But this seems weird, since what is
relevant is what is actually going on under the hood.
Or, on the other hand, changing 'condition-evaluation' should change the
state of all breakpoints; but this requires additional code AFAICT.
Luis> +int remote_supports_cond_breakpoints (void);
Is it much uglier to rearrange things so no forward declaration is
needed?
Luis> + /* List of conditions the target should evaluate if it supports target-side
Luis> + breakpoint conditions. */
Luis> + struct condition_list *cond_list;
It seems that the callee must free these. I think that should be
documented here.
Luis> + /* Conditional expression in agent expression
Luis> + bytecode form. This is used for stub-side breakpoint
Luis> + condition evaluation. */
Luis> + struct agent_expr *cond_bytecode;
Luis> +
Luis> + /* Signals that the condition has changed since the last time
Luis> + we updated the global location list. This means the condition
Luis> + needs to be sent to the target again. This is used together
Luis> + with target-side breakpoint conditions. */
Luis> + int condition_changed;
Luis> +
Luis> + /* Signals that breakpoint conditions need to be re-synched with the
Luis> + target. This has no use other than target-side breakpoints. */
Luis> + int needs_update;
I still wish we had 'bool'. Maybe this year.
pahole says there are holes in bp_location on my x86-64 box. I think it
is somewhat preferable to fill the holes and to follow existing
practice, that is, use 'char' for boolean fields here.
My preference would be to use 'unsigned int : 1' for boolean fields, but
I don't know how others feel about this.
Tom
next prev parent reply other threads:[~2012-01-06 21:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-05 14:56 Luis Machado
2012-01-06 8:47 ` Eli Zaretskii
2012-01-06 22:38 ` Luis Machado
2012-01-07 7:54 ` Eli Zaretskii
2012-01-12 19:44 ` Pedro Alves
2012-01-12 22:20 ` Tom Tromey
2012-01-13 8:08 ` Eli Zaretskii
2012-01-13 14:33 ` Tom Tromey
2012-01-13 14:44 ` Pedro Alves
2012-01-06 16:23 ` Pedro Alves
2012-01-10 11:14 ` Luis Machado
2012-01-12 19:31 ` Pedro Alves
2012-01-06 21:44 ` Tom Tromey [this message]
2012-01-10 14:51 ` Luis Machado
2012-01-13 15:36 ` Yao Qi
2012-01-13 18:13 ` Pedro Alves
2012-01-14 0:42 ` Yao Qi
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=m3aa601p6q.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=luis_gustavo@mentor.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