public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@redhat.com>
To: gdb-patches@sourceware.org
Cc: Andrew Burgess <aburgess@redhat.com>
Subject: [PATCHv2 0/3] Improve debug output support in gdbserver
Date: Thu, 30 Nov 2023 18:44:15 +0000	[thread overview]
Message-ID: <cover.1701369189.git.aburgess@redhat.com> (raw)
In-Reply-To: <cover.1699379375.git.aburgess@redhat.com>

Changes since v1:

  - I've now dropped the --remote-debug and --event-loop-debug command
    line options,

  - I've now dropped the 'monitor set remote-debug' and 'monitor set
    event-loop-debug' monitor commands,

  - I've fixed some of Eli's doc feedback.  We still have the
    duplication between the man page and info manual content.  I'm not
    sure if that can easily be fixed as part of this commit, or if
    that should be a separate piece of work,

  - Now accept on/off instead of 1/0 in the monitor commands,

  - Now allow 'all' as a component in the monitor commands.
    Preventing this before was pretty arbitrary, and on reflection
    seemed pointless,

  - Fixed a bug where the 'all' component would only actually enable
    the 'threads' component,

  - The first patch of the prevoius series has been pushed.  But I
    have a new first patch which fixes another gdbserver debug related
    issue.

---

For another patch I'm working on I wanted to add some additional debug
output to gdbserver.

Right now there appears to be two broad approaches I could take, these are:

  1. Just use threads_debug_printf.  The comments in debug.h even
  claim that this is really the "general" gdbserver debug output and
  that the "threads" here is just historic, but that feels like a bit
  of a cop out, we do have separate remote and event-loop debug
  control.  I think what really happened is folk just started reusing
  the threads_debug_printf rather than adding a new debug category,
  and over time we just resigned ourselves to threads actually being
  general output...  I think we can do better than that, so

  2. We can add a whole new debug category, with a new *_debug_printf
  function.  That I think would be better, but to control this new
  debug flag we then need to add a new command line flag (we already
  have --debug, --remote-debug, and --event-loop-debug), and then we
  need to add new monitor commands to control this new debug
  setting... this begins to feel not very scalable.

So, in this series I try to reimagine debug control in gdbserver.

The gdbserver command line flag now takes an optional list of
components, so we can do:

  gdbserver --debug=remote,threads

to enable 'remote' and 'threads' debug.  The default if no components
are listed is 'threads', which retains backwards compatibility with
the current behaviour, thought we might want to change this in the
future.

I've also removed the two existing flags '--remote-debug' and
'--event-loop-debug', instead we should now do '--debug=remote',
'--debug=event-loop', or '--debug=remote,event-loop' as needed.

And on the monitor command side, we now support:

  (gdb) monitor set debug COMPONENT on
  (gdb) monitor set debug COMPONENT off

to enable and disable debug for COMPONENT.  Where COMPONENT is again,
'all', 'threads', 'remote', and 'event-loop'.  Again, I've retained:

  (gdb) monitor set debug on

As a synonym for 'monitor set debug threads on', but I have changed:

  (gdb) monitor set debug off

Which now disables all debugging output from gdbserver.  Notice also
that I'm not using 'on' and 'off' in the monitor commands rather than
'1' and '0'.  The old 1/0 still works, but on/off is what the docs now
suggest; this seemed to better match GDB's internal settings.

I have removed the monitor command:

  (gdb) monitor set remote-debug 0|1
  (gdb) monitor set event-loop-debug 0|1

These commands are replaces by using the 'remote' or 'event-loop'
components as needed.

---

Andrew Burgess (3):
  gdb: fix GDB_DEBUG and GDBSERVER_DEBUG Makefile variables
  gdbserver: allow the --debug command line option to take a value
  gdbserver: allow for general 'monitor set debug COMPONENT VALUE' use

 gdb/Makefile.in                         |   5 +-
 gdb/NEWS                                |  18 ++
 gdb/doc/gdb.texinfo                     |  98 ++++++--
 gdb/testsuite/gdb.server/server-mon.exp |  25 +-
 gdbserver/server.cc                     | 315 +++++++++++++++++++++---
 5 files changed, 397 insertions(+), 64 deletions(-)


base-commit: a393b155174d20d3d120b5012b87c5438ab9e3d4
-- 
2.25.4


  parent reply	other threads:[~2023-11-30 18:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-07 18:03 [PATCH " Andrew Burgess
2023-11-07 18:03 ` [PATCH 1/3] gdbserver: cleanup monitor_show_help Andrew Burgess
2023-11-22 15:21   ` Andrew Burgess
2023-11-07 18:03 ` [PATCH 2/3] gdbserver: allow the --debug command line option to take a value Andrew Burgess
2023-11-07 19:41   ` Eli Zaretskii
2023-11-30 18:31     ` Andrew Burgess
2023-11-30 19:20       ` Eli Zaretskii
2023-12-04 15:57         ` Andrew Burgess
2023-12-04 16:21           ` Eli Zaretskii
2023-12-05 10:17             ` Andrew Burgess
2023-12-05 13:06               ` Eli Zaretskii
2023-11-07 18:03 ` [PATCH 3/3] gdbserver: allow for general 'monitor set debug COMPONENT VALUE' use Andrew Burgess
2023-11-17 14:43 ` [PATCH 0/3] Improve debug output support in gdbserver Tom Tromey
2023-11-17 14:55 ` Tom Tromey
2023-11-30 18:44 ` Andrew Burgess [this message]
2023-11-30 18:44   ` [PATCHv2 1/3] gdb: fix GDB_DEBUG and GDBSERVER_DEBUG Makefile variables Andrew Burgess
2023-11-30 18:44   ` [PATCHv2 2/3] gdbserver: allow the --debug command line option to take a value Andrew Burgess
2023-11-30 18:44   ` [PATCHv2 3/3] gdbserver: allow for general 'monitor set debug COMPONENT VALUE' use Andrew Burgess
2023-11-30 19:30     ` Eli Zaretskii
2023-12-01 18:02   ` [PATCHv2 0/3] Improve debug output support in gdbserver Tom Tromey
2023-12-08 18:03     ` Andrew Burgess

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=cover.1701369189.git.aburgess@redhat.com \
    --to=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /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).