Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Skip gdb.base/break.exp catchpoint tests without catchpoints [PR34535]
Date: Fri, 21 Aug 2026 09:16:52 -0600	[thread overview]
Message-ID: <87tsonsduj.fsf@tromey.com> (raw)
In-Reply-To: <yddse48j2xg.fsf@CeBiTec.Uni-Bielefeld.DE> (Rainer Orth's message of "Thu, 20 Aug 2026 16:12:59 +0200")

>>>>> "Rainer" == Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:

Rainer> As detailed in PR PR testsuite/34535, the gdb.base/break.exp test FAILs
Rainer> on Solaris:

Thanks for the patch.

Rainer> While this patch avoids the failure, I wonder if there's some document
Rainer> on what it takes to actually implement catchpoints.

There's not really docs on anything.  However, most catchpoints are
implemented in break-catch-*.c.  Looking at break-catch-fork.c:

int
fork_catchpoint::insert_location (struct bp_location *bl)
{
  if (is_vfork)
    return target_insert_vfork_catchpoint (inferior_ptid.pid ());
  else
    return target_insert_fork_catchpoint (inferior_ptid.pid ());
}

So basically the target has to implement the insert_fork_catchpoint
target method; then arrange to tell gdb about TARGET_WAITKIND_FORKED
when appropriate.

Unfortunately the target methods don't have comments; while we try to
add descriptions nowadays, in the past gdb was lax about this :(
But there's a "paragraph" of them in target.h that you'd probably need
to handle:

    virtual int insert_fork_catchpoint (int)
      TARGET_DEFAULT_RETURN (1);
    virtual int remove_fork_catchpoint (int)
      TARGET_DEFAULT_RETURN (1);
    virtual int insert_vfork_catchpoint (int)
      TARGET_DEFAULT_RETURN (1);
    virtual int remove_vfork_catchpoint (int)
      TARGET_DEFAULT_RETURN (1);
    virtual void follow_fork (inferior *, ptid_t, target_waitkind, bool, bool)
      TARGET_DEFAULT_FUNC (default_follow_fork);

Rainer> +    set test "probe fork catchpoint"
Rainer> +    gdb_test_multiple "" $test {
Rainer> +	-re "Your system does not support this type.*" {
Rainer> +	    unsupported $test
Rainer> +	}
Rainer> +	-re "$::gdb_prompt $" {
Rainer> +	    set ::fork_catchpoints_supported 1
Rainer> +	    pass $test
Rainer> +	}
Rainer> +    }
Rainer> +}
 
Rainer> +    if {!$::fork_catchpoints_supported} {
Rainer> +	return
Rainer> +    }
Rainer> +
Rainer>      gdb_test "catch fork" "Catchpoint ${::decimal} \\(fork\\)" \
Rainer>  	"set catch fork, never expected to trigger"
 
I think it would be better to just use gdb_test_multiple here, and if
the "not supported" case is found, just return here.  That would avoid
starting another gdb.

thanks,
Tom

  reply	other threads:[~2026-08-21 15:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-20 14:12 Rainer Orth
2026-08-21 15:16 ` Tom Tromey [this message]
2026-08-22 20:14   ` [PATCH v2] Handle missing catchpoint support in gdb.base/break.exp [PR34535] Rainer Orth
2026-08-27 15:33     ` Tom Tromey

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=87tsonsduj.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=gdb-patches@sourceware.org \
    --cc=ro@CeBiTec.Uni-Bielefeld.DE \
    /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