GNU bug report logs - #66363
gdb-control-commands-regexp issues

Previous Next

Full log

Message #13 received at 66363 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66363 <at> debbugs.gnu.org
Subject: Re: bug#66363: gdb-control-commands-regexp issues
Date: Thu, 5 Oct 2023 19:16:32 +0200

> I'd appreciate a few examples of using this that don't work correctly
> (or not at all), as it is otherwise not easy to understand the
> problem, and much less the proposed solution and how to test it.

I don't have any examples but the problems are clear from reading the code.
The regexp is defined by:

> (defvar gdb-python-guile-commands-regexp
>   "python\\|python-interactive\\|pi\\|guile\\|guile-repl\\|gr"
>   "Regexp that matches Python and Guile commands supported by GDB.")
> 
> (defvar gdb-control-commands-regexp
>   (concat
>    "^\\("
>    "comm\\(a\\(n\\(ds?\\)?\\)?\\)?\\|if\\|while"
>    "\\|def\\(i\\(ne?\\)?\\)?\\|doc\\(u\\(m\\(e\\(nt?\\)?\\)?\\)?\\)?\\|"
>    gdb-python-guile-commands-regexp
>    "\\|while-stepping\\|stepp\\(i\\(ng?\\)?\\)?\\|ws\\|actions"
>    "\\|expl\\(o\\(re?\\)?\\)?"
>    "\\)\\([[:blank:]]+\\([^[:blank:]]*\\)\\)*$")
>   "Regexp matching GDB commands that enter a recursive reading loop.
> As long as GDB is in the recursive reading loop, it does not expect
> commands to be prefixed by \"-interpreter-exec console\".")

which results in the string regexp

> "^\\(comm\\(a\\(n\\(ds?\\)?\\)?\\)?\\|if\\|while\\|def\\(i\\(ne?\\)?\\)?\\|doc\\(u\\(m\\(e\\(nt?\\)?\\)?\\)?\\)?\\|python\\|python-interactive\\|pi\\|guile\\|guile-repl\\|gr\\|while-stepping\\|stepp\\(i\\(ng?\\)?\\)?\\|ws\\|actions\\|expl\\(o\\(re?\\)?\\)?\\)\\([[:blank:]]+\\([^[:blank:]]*\\)\\)*$"

It is used in one place only:

>   (let* ((control-command-p (string-match gdb-control-commands-regexp string))
>          (command-arg (and control-command-p (match-string 3 string)))

As you can see it refers to group 3, which is matched by "\\(n\\(ds?\\)?\\)" -- clearly not what anybody intended.

As for the tail, even if the match group is corrected it's a rather roundabout way of checking whether there is a non-blank character after the command (and is written using nested repetitions which is how this came to my attention).

For the examples you asked about, perhaps commit 30c0f81f9f which introduced the now broken mechanism can be of help.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.