From: "Aktemur, Tankut Baris" <tankut.baris.aktemur@intel.com>
To: Simon Marchi <simark@simark.ca>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: RE: [PATCH 2/3] gdb/breakpoint: set the condition exp after parsing the condition successfully
Date: Wed, 22 Jul 2020 15:29:43 +0000 [thread overview]
Message-ID: <SN6PR11MB2893768AE00713FAB4DE20D7C4790@SN6PR11MB2893.namprd11.prod.outlook.com> (raw)
In-Reply-To: <368bbad3-67c4-1422-9006-8a37ac49be34@simark.ca>
On Wednesday, July 22, 2020 3:28 PM, Simon Marchi wrote:
> Although, in the breakpoint case, when we have:
>
> for (bp_location *loc = b->loc; loc != nullptr; loc = loc->next)
> {
> const char *arg = exp;
> expression_up new_exp
> = parse_exp_1 (&arg, loc->address,
> block_for_pc (loc->address), 0);
> if (*arg != 0)
> error (_("Junk at end of expression"));
> loc->cond = std::move (new_exp);
> }
>
> Doesn't that mean that if the expression succeeds to parse for one location and then
> fails to parse for another location, we'll have updated one location and not the other?
Ahh, yes. The diff for the part above should have been:
struct bp_location *loc;
+ /* Parse and set condition expressions. We make two passes.
+ In the first, we parse the condition string to see if it
+ is valid in all locations. If so, the condition would be
+ accepted. So we go ahead and set the locations'
+ conditions. In case a failing case is found, we throw
+ the error and the condition string will be rejected.
+ This two-pass approach is taken to avoid setting the
+ state of locations in case of a reject. */
+ for (loc = b->loc; loc; loc = loc->next)
+ {
+ arg = exp;
+ parse_exp_1 (&arg, loc->address,
+ block_for_pc (loc->address), 0);
+ if (*arg != 0)
+ error (_("Junk at end of expression"));
+ }
+
+ /* If we reach here, the condition is valid at all locations. */
for (loc = b->loc; loc; loc = loc->next)
{
arg = exp;
loc->cond =
parse_exp_1 (&arg, loc->address,
block_for_pc (loc->address), 0);
- if (*arg)
- error (_("Junk at end of expression"));
}
> How does that work (or should work) when we have a multi-location breakpoint and the
> condition only makes sense in one of the locations?
I'm in fact working on a follow-up patch on this topic, where the two-pass approach above
is used (hence I forgot to include it in this series).
Currently, GDB expects the condition to be valid at all locations. The patch that I'll
soon post proposes to accept the condition if there exist locations where it's valid.
The locations where the condition is invalid are disabled. But in the current state, the
condition has to make sense at all locations.
Thanks
-Baris
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
next prev parent reply other threads:[~2020-07-22 15:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-29 13:48 [PATCH 0/3] Prevent bad conditions from putting breakpoints into broken state Tankut Baris Aktemur
2020-06-29 13:48 ` [PATCH 1/3] gdb/breakpoint: do not update the condition string if parsing the condition fails Tankut Baris Aktemur
2020-07-22 13:12 ` Simon Marchi
2020-07-22 13:15 ` Simon Marchi
2020-06-29 13:48 ` [PATCH 2/3] gdb/breakpoint: set the condition exp after parsing the condition successfully Tankut Baris Aktemur
2020-07-22 13:21 ` Simon Marchi
2020-07-22 13:28 ` Simon Marchi
2020-07-22 15:29 ` Aktemur, Tankut Baris [this message]
2020-07-22 16:06 ` Simon Marchi
2020-07-23 7:11 ` Aktemur, Tankut Baris
2020-07-30 10:56 ` Aktemur, Tankut Baris
2020-07-30 15:15 ` Simon Marchi
2020-06-29 13:48 ` [PATCH 3/3] gdb/breakpoint: refactor 'set_breakpoint_condition' Tankut Baris Aktemur
2020-07-13 8:45 ` [PATCH 0/3] Prevent bad conditions from putting breakpoints into broken state Tankut Baris Aktemur
2020-07-21 9:08 ` Tankut Baris Aktemur
2020-07-22 18:24 ` Pedro Alves
2020-07-23 7:13 ` Aktemur, Tankut Baris
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=SN6PR11MB2893768AE00713FAB4DE20D7C4790@SN6PR11MB2893.namprd11.prod.outlook.com \
--to=tankut.baris.aktemur@intel.com \
--cc=gdb-patches@sourceware.org \
--cc=simark@simark.ca \
/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