RE: [PATCHv6 06/10] gdb: parse pending breakpoint thread/task immediately

Aktemur, Tankut Baris
2023-12-05T15:10:25Z

On Saturday, December 2, 2023 11:42 AM, Andrew Burgess wrote:
> diff --git a/gdb/break-cond-parse.c b/gdb/break-cond-parse.c
> new file mode 100644
> index 00000000000..b59bd7aeeec
> --- /dev/null
> +++ b/gdb/break-cond-parse.c
> @@ -0,0 +1,463 @@
> +/* Copyright (C) 2023 Free Software Foundation, Inc.
> +
> + This file is part of GDB.
> +
> + This program is free software; you can redistribute it and/or modify
> + it under the terms of the GNU General Public License as published by
> + the Free Software Foundation; either version 3 of the License, or
> + (at your option) any later version.
> +
> + This program is distributed in the hope that it will be useful,
> + but WITHOUT ANY WARRANTY; without even the implied warranty of
> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + GNU General Public License for more details.
> +
> + You should have received a copy of the GNU General Public License
> + along with this program. If not, see <http://www.gnu.org/licenses/>. */
> +
> +#include "defs.h"
> +#include "gdbsupport/gdb_assert.h"
> +#include "gdbsupport/selftest.h"
> +#include "test-target.h"
> +#include "scoped-mock-context.h"
> +#include "break-cond-parse.h"
> +#include "tid-parse.h"
> +#include "ada-lang.h"
> +
> +/* When parsing tokens from a string, which direction are we parsing?
> +
> + Given the following string and pointer 'ptr':
> +
> + ABC DEF GHI JKL
> + ^
> + ptr
> +
> + Parsing 'forward' will return the token 'GHI' and update 'ptr' to point
> + between GHI and JKL. Parsing 'backward' will return the token 'DEF' and
> + update 'ptr' to point between ABC and DEF.
> +*/
> +
> +enum class parse_direction
> +{
> + /* Parse the next token forwards. */
> + forward,
> +
> + /* Parse the previous token backwards. */
> + backward
> +};
> +
> +struct token
> +{
> + /* Create a new token. START points to the first character of the new
> + token, while END points at the last character of the new token.
> +
> + Neither START or END can be nullptr, and both START and END must point
> + into the same C style string (i.e. there should be no null character
> + between START and END). END must be equal to, or greater than START,
> + that is, it is not possible to create a zero length token. */
> +
> + token (const char *start, const char *end)

Have you considered using std::string_view?

> + : m_start (start),
> + m_end (end)
> + {
> + gdb_assert (m_end >= m_start);
> + gdb_assert (m_start + strlen (m_start) > m_end);
> + }
> +
> + /* Return a pointer to the first character of this token. */
> + const char *start () const
> + {
> + return m_start;
> + }
> +
> + /* Return a pointer to the last character of this token. */
> + const char *end () const
> + {
> + return m_end;
> + }
> +
> + /* Return the length of the token. */
> + size_t length () const
> + {
> + /* The + 1 is because the character at m_end is part of the token. */
> + return m_end - m_start + 1;
> + }
> +
> + /* Return true if this token matches STR. */
> + bool matches (const char *str) const
> + {
> + return strncmp (m_start, str, length ()) == 0;
> + }
> +
> +private:
> + /* The first character of this token. */
> + const char *m_start;
> +
> + /* The last character of this token. */
> + const char *m_end;
> +};
> +
> +/* Find the next token in DIRECTION from *CURR. */
> +
> +static token
> +find_next_token (const char **curr, parse_direction direction)
> +{
> + const char *tok_start, *tok_end;
> +
> + gdb_assert (**curr != '\0');
> +
> + if (direction == parse_direction::forward)
> + {
> + *curr = skip_spaces (*curr);
> + tok_start = *curr;
> + *curr = skip_to_space (*curr);
> + tok_end = *curr - 1;
> + }
> + else
> + {
> + gdb_assert (direction == parse_direction::backward);
> +
> + while (isspace (**curr))
> + --(*curr);
> +
> + tok_end = *curr;
> +
> + while (!isspace (**curr))
> + --(*curr);
> +
> + tok_start = (*curr) + 1;
> + }
> +
> + return token (tok_start, tok_end);
> +}
> +
> +/* See break-cond-parse.h. */
> +
> +void
> +create_breakpoint_parse_arg_string
> + (const char *tok, gdb::unique_xmalloc_ptr<char> *cond_string,
> + int *thread, int *inferior, int *task,
> + gdb::unique_xmalloc_ptr<char> *rest, bool *force)
> +{
> + /* Set up the defaults. */
> + cond_string->reset ();
> + rest->reset ();
> + *thread = -1;
> + *inferior = -1;
> + *task = -1;
> + *force = false;
> +
> + if (tok == nullptr)
> + return;
> +
> + /* The "-force-condition" flag gets some special treatment. If this
> + token is immediately after the condition string then we treat this as
> + part of the condition string rather than a separate token. This is
> + just a quirk of how this token used to be parsed, and has been
> + retained for backwards compatibility. Maybe this should be updated
> + in the future. */

(I was the author of the -force-condition patch.)
The quirks about the -force-condition flag were not a deliberate feature.
For whatever it's worth, I think it's OK to de-prioritize backwards
compatibility for this flag. I doubt that it would impact many users.

In fact, in a post-merge comment, Pedro and Tom had suggested converting
the flag to an option rather than a keyword:

https://sourceware.org/pipermail/gdb-patches/2020-October/172952.html
https://sourceware.org/pipermail/gdb-patches/2020-December/173802.html
https://sourceware.org/pipermail/gdb-patches/2020-December/173999.html

I (embarrassingly) did not have the opportunity to get back to it. Maybe
it's now the correct time to address the concerns? I can gladly help.
What do you think?

...
> try
> {
> ops->create_sals_from_location_spec (locspec, &canonical);
> @@ -9285,6 +9122,13 @@ create_breakpoint (struct gdbarch *gdbarch,
> throw;
> }
>
> + /* The only bp_dprintf should have anything in EXTRA_STRING_COPY by this

This sentence sounds odd. Did you mean "Only the bp_dprintf type should have..."?

> + point. For all other breakpoints this indicates an error. We could
> + place this check earlier in the function, but we prefer to see errors
> + from the location spec parser before we see this error message. */
> + if (type_wanted != bp_dprintf && extra_string_copy.get () != nullptr)
> + error (_("Garbage '%s' at end of command"), extra_string_copy.get ());
> +
> if (!pending && canonical.lsals.empty ())
> return 0;
>

Regards
-Baris

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928