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

Message ID 2793a93ca9aa228f432650743674cb481881e9db.1682724005.git.aburgess@redhat.com
State New
Headers
Series thread-specific breakpoints in just some inferiors |

Commit Message

Andrew Burgess April 28, 2023, 11:35 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(-)
  

Patch

diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index 350fa495319..b75990963ca 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -8382,8 +8382,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);