[PATCHv3,3/9] gdb: change 'if' to gdb_assert in update_dprintf_command_list

Message ID 09152d06a4099a28ec03bf4e3167bdf6287da1ef.1685479504.git.aburgess@redhat.com
State New
Series thread-specific breakpoints in just some inferiors |

Commit Message

Andrew Burgess May 30, 2023, 8:46 p.m. UTC
  I noticed in update_dprintf_command_list that we handle the case where
the bp_dprintf style breakpoint doesn't have a format and args string.

However, I don't believe such a situation is possible.  The obvious
approach certainly already catches this case:

  (gdb) dprintf main
  Format string required

If it is possible to create a dprintf breakpoint without a format and
args string then I think we should be catching this case and handling
it at creation time, rather than having GDB just ignore the situation
later on.

And so, I propose that we change the 'if' that ignores the case where
the format/args string is empty, and instead assert that we do always
have a format/args string.  The original code, that handled an empty
format/args string has existed since commit e7e0cddfb0d4, which is
when dprintf support was added to GDB.

If I'm correct and this situation can't ever happen then there should
be no user visible changes after this commit.
 gdb/breakpoint.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)


diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index fcd2f472bf7..2cadc8c0295 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -8356,8 +8356,9 @@  update_dprintf_command_list (struct breakpoint *b)
   const char *dprintf_args = b->extra_string.get ();
   gdb::unique_xmalloc_ptr<char> printf_line = nullptr;
-  if (!dprintf_args)
-    return;
+  /* Trying to create a dprintf breakpoint without a format and args
+     string should be detected at creation time.  */
+  gdb_assert (dprintf_args != nullptr);
   dprintf_args = skip_spaces (dprintf_args);