public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: "Aktemur, Tankut Baris" <tankut.baris.aktemur@intel.com>,
	"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 12:06:26 -0400	[thread overview]
Message-ID: <c69900b5-b382-4a72-2d7e-3e3241a2071b@simark.ca> (raw)
In-Reply-To: <SN6PR11MB2893768AE00713FAB4DE20D7C4790@SN6PR11MB2893.namprd11.prod.outlook.com>

On 2020-07-22 11:29 a.m., Aktemur, Tankut Baris wrote:
> 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.

Ok, so do you want to wait and post everything together, or do still want to consider
merging this one on its own, since it's still a step forward?

Simon

  reply	other threads:[~2020-07-22 16:06 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
2020-07-22 16:06         ` Simon Marchi [this message]
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=c69900b5-b382-4a72-2d7e-3e3241a2071b@simark.ca \
    --to=simark@simark.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=tankut.baris.aktemur@intel.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).