Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: "Gerlicher, Klaus" <klaus.gerlicher@intel.com>,
	Kevin Buettner <kevinb@redhat.com>, Tom Tromey <tom@tromey.com>,
	Pedro Alves <pedro@palves.net>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH 1/1] gdb, breakpoint: use breakpoint_debug_printf
Date: Fri, 11 Jul 2025 11:22:42 -0400	[thread overview]
Message-ID: <615bf390-6aca-4783-a142-2c07c6aeec95@simark.ca> (raw)
In-Reply-To: <DM3PPFD7E67F0365072DAA454401623D2C7E848A@DM3PPFD7E67F036.namprd11.prod.outlook.com>

On 7/10/25 4:43 AM, Gerlicher, Klaus wrote:
> Hi, 
> 
> Thanks for the quick response. I see, we need to include Pedro then I guess. It's 
> not terribly important, I was just adding some things to breakpoint for our purposes 
> and I hit this oddity.
> 
> +Pedro
> 
> Thanks
> Klaus

I agree with Tom, it's not just the file that dictates which "debug
print" function to use, it's also what the code does.  You have to ask
yourself, when would I want to see this debug print.  This is how I see
it:

 - "infrun" is about GDB controlling the threads, handling target
   events, resuming threads, stopping threads, etc.
 - "breakpoint" is about the actions of inserting or removing
   breakpoints, computing the locations of breakpoints, etc.

You have to ask yourself, when would you like to see each statement.
The code in bpstat_check_breakpoint_conditions, for instance, is about
evaluating a breakpoint condition after a thread has hit it.  I think
these debug prints are useful to have when debugging infrun issues,
when you ask yourself "why did GDB decide to stop/not stop this thread".

It's possible that some of these infrun prints should be breakpoint
prints, but it needs to be more thought out.

I see that breakpoint_debug_printf is only used at 5 spots, which is
surprising, since the breakpoint machinery is rather complex and core to
GDB.  It is relatively recent (2023), so it perhaps just means we need
to add more of them, when we debug issues.

Simon

  reply	other threads:[~2025-07-11 15:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-08 13:21 Klaus Gerlicher
2025-07-08 15:46 ` Kevin Buettner
2025-07-09 19:21 ` Tom Tromey
2025-07-10  2:58   ` Kevin Buettner
2025-07-10  8:43     ` Gerlicher, Klaus
2025-07-11 15:22       ` Simon Marchi [this message]
2025-07-17 17:02       ` 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=615bf390-6aca-4783-a142-2c07c6aeec95@simark.ca \
    --to=simark@simark.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=kevinb@redhat.com \
    --cc=klaus.gerlicher@intel.com \
    --cc=pedro@palves.net \
    --cc=tom@tromey.com \
    /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