From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id AlkDLjhWOmrCrhQAWB0awg (envelope-from ) for ; Tue, 23 Jun 2026 05:47:36 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=OUvJPct0; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id A73A31E024; Tue, 23 Jun 2026 05:47:36 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 967B71E024 for ; Tue, 23 Jun 2026 05:47:34 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 69CEA4BA2E1E for ; Tue, 23 Jun 2026 09:47:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 69CEA4BA2E1E Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=OUvJPct0 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 12C294BA2E24 for ; Tue, 23 Jun 2026 09:46:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 12C294BA2E24 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 12C294BA2E24 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782207984; cv=none; b=LU/peSBRbWnhhH8sHi9Kpp42nFHRV+eWjVWi86EE8yhU8HR9jniQHNsrMb8f6QloAGRKZUnN9rLn1x7JZDojp+xAXfSsOF2PCHtSCY5Nygrwr96FcpzKgsgnCSHN6RT5jeQHMsike8NN+gZC0zZoto23gHpL7JHiz6Xm1TqT1Ls= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782207984; c=relaxed/simple; bh=HZxB2QkxuGUCea4WosVgDDnphP60hDzrNpAh4YTeWKU=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=Ig6OfDGAYIN3mL9ZwbUiPDpYP0b1TfGJTdjTRlmsRG8RwMyV1FmfH4vY+X4vAlb65tmqAehE05AMwKVWHge0Qh8X8vqxFqnrAVEf2QhyQ50mWAvuMqA5rnHx8Jz2cVHEi3SCKrL91XU08KN978201z9/hoy1RsagBQGSP3P0oSU= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=OUvJPct0 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 12C294BA2E24 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782207983; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=b077L6ifWLdmloCIlZjNjIXOmq/eLN4duXHjEo2KaAk=; b=OUvJPct0gIuQOmNbXDu7tkR84NMwj/HJY8e4JdlSv3icOa5fwaCyTTIAccnMHCToThxM7W 96Rd2WE8LJdjBcPmuRXE0MckOXnHJp/ZTMtXXX9qGRNYVsqXICGZsk6FxEGlZDgREqlroO 6o0kf3YOogY8GkQFo3w8BqiP/0URAnU= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-251-8ShnQTiPN76L4Jf_eqxCdA-1; Tue, 23 Jun 2026 05:46:22 -0400 X-MC-Unique: 8ShnQTiPN76L4Jf_eqxCdA-1 X-Mimecast-MFC-AGG-ID: 8ShnQTiPN76L4Jf_eqxCdA_1782207981 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-490a767b782so37500905e9.2 for ; Tue, 23 Jun 2026 02:46:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782207981; x=1782812781; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=b077L6ifWLdmloCIlZjNjIXOmq/eLN4duXHjEo2KaAk=; b=c0NtDmprRu1OfDkJfUcM4beU7cq69opinJsKk/s0fmUP/7yRQv60OqQ3uKVwTq5x7G IBAF2JWei5D8tiV9gK1qs90jg4lURSzWCNNRVWJl4g0E7MwkqPgiwxCRx0VjgihPZdCE xQOaF9SyU6tDLxXJ3Ps2nvQ+2I315J+jtTvmcs8pluomKR2i/eXbtU0BK6Z7Vm5XAWIL jEgTy3/HWVNPHSr/w+Y8r629S2AxPYcPikn3xmHiLle5ZdMG/PdmEqiFpn2Z0yWVtF/W +CzT2iH3eRfaKJkzWt8U/vP60khru0TEwz/BQyJaE14Ja9RtQ+1+OHDsIHKVPmj4vOkx 2gYQ== X-Forwarded-Encrypted: i=1; AFNElJ+gAl0NMb4Zw/LzCNIJij3tp1oWQsPQTl59tv67xIrSkRorvahxBwP2Gsq2t2D0x3dHjF6WNOY3vCK/RA==@sourceware.org X-Gm-Message-State: AOJu0YzYlkKOFzcQ4UPs4+tDxRRg9L6Ccvm+RG2E9jdm1FE/C/KCU57r vhKnK3FYiy8pZYdmMmZUMlxyuQeGDjqIIEIymlTdlG1PJSD1vHZvlNYYyhZzz0dyHk6Az+orSRK qsbY8izq3MQcwoItqi/bJqfE9YM7JzU4lcaF7y6tXr9UV4zfITzYWjLegfdN2icRDGO91T2c= X-Gm-Gg: AfdE7ckDRGEhqzI7v3Ruml6yPRQMHedoq7vm4E3g+oAs459+eNo51dtmr/wDD3dBSq8 ymIXsvS6WwxhGtpq5AWpV1DBa72WfA6fH9QsPxY+mvffi4l6u4ghOSRnWTal/oU1Jd8NzTUvlo1 RGxgKeN4tlhAKvjjk+nIddADMVT/KbUuzeZRze8THWtKin2XEXBg+6nGNyqplqri7FUUh4IJCFI YtUfUv0ie1DRO0EjAJ/Z6fRYHTyCujj+5FNozDREocK9QyrMaL8xNR+0xGHyLKUO6Xv8YJUPPtp RcPQFFzd4mjbnj73TVXSZP6XLSqpMZfNu0WW+zfkn7vcCVkqyFi9z2OqTcwnx6kO0QNlJIQCqqY qNooun3AgX9wKGoTmVnyDTG3SB1H9Bg== X-Received: by 2002:a05:600c:8716:b0:490:c032:ae92 with SMTP id 5b1f17b1804b1-49240ea870emr276652825e9.33.1782207981170; Tue, 23 Jun 2026 02:46:21 -0700 (PDT) X-Received: by 2002:a05:600c:8716:b0:490:c032:ae92 with SMTP id 5b1f17b1804b1-49240ea870emr276652325e9.33.1782207980683; Tue, 23 Jun 2026 02:46:20 -0700 (PDT) Received: from localhost (19.81.93.209.dyn.plus.net. [209.93.81.19]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-46666788282sm50392211f8f.17.2026.06.23.02.46.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jun 2026 02:46:20 -0700 (PDT) From: Andrew Burgess To: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [PATCHv2 2/3] gdb: introduce program_space::get_entry_point_info function In-Reply-To: References: <41fe591d58ba010fa771e80ca674b61e30feef2f.1780942441.git.aburgess@redhat.com> <864cefb52d208dd8aac6b1b5f452cadad7546af8.1781214731.git.aburgess@redhat.com> <87fr2op04p.fsf@redhat.com> Date: Tue, 23 Jun 2026 10:46:19 +0100 Message-ID: <87zf0loahg.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 5OefX7q5gkQATB10LRm1keIwNa0Y6bYdHU3DQeGLe1M_1782207981 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Pedro Alves writes: > Hi! > > On 2026-06-15 11:29, Andrew Burgess wrote: >> Pedro Alves writes: >> >>> On 2026-06-11 22:59, Andrew Burgess wrote: >>>> + # Only svr4 targets currently support querying the inferior entry >>>> + # address. >>>> + if {[istarget *-linux*]} { >>> >>> There are more svr4 targets than linux. I think this style of allow-list has >>> a good chance of never getting updated. Deny-lists are better, IMHO. If the >>> test fails on some port, that might trigger someone to add the feature >>> there. >> >> Hey Pedro, >> >> I'm still looking at your other feedback, but before I start making this >> specific change, I just wanted to clarify how you see this as being >> different from what I have right now. >> >> If I write this as a deny list, e.g. >> >> if { ![istarget ....] && ![istarget ....] } { >> # Run tests. >> } >> >> Is there not the same problem? We rely on someone realising that the >> reason the test isn't run on their target is some missing GDB >> functionality, and them adding the functionality and removing the >> `istarget` block for their target. > > > Speaking from principles, and not this particular case: > > The difference is that there was a failure that made someone see that > some functionality is missing. With the allow-list, nobody ever notices it. > > With a target-based allow-list, even if someone adds some functionality > to a port, it's typical to not comb through the testsuite and > relax the relevant allow-lists to also allow their targets. > > And even if they want to, there's no easy marker to grep for. E.g, say I > implement feature X on Windows, then how do I know that I need to > grep for "istarget Y" to find all the tests that I need to adjust? > And which Y? And then which ones that hit my grep should I look at? > > I'll give you one example, in gdb.threads/watchpoint-fork.exp: > > # Only GNU/Linux is known to support `set follow-fork-mode child'. > if {[istarget "*-*-linux*"]} { > test child FOLLOW_CHILD > } else { > untested "${testfile}: child" > } > > I think at least FreeBSD has supported that for over a decade. Sure, but how would rewriting this as you're suggesting have helped in any way? From what you suggest below I'm imagining your rewrite of this would have looked like this: if { [supports_fork_follow_child] } { test child FOLLOW_CHILD } else { untested "${testfile}: child" } with: proc supports_fork_follow_child {} { if { [istarget *-freebsd*] } { # Not supported here. I assume at the point the test was first # added this feature wasn't supported on FreeBSD. return 0 } # Assume true by default. return 1 } Now, I agree that this is better as fixing `supports_fork_follow_child` means we only need to update one proc and all tests that used the proc would then start testing fork follow child behaviour. But, as you say, it's unlikely that when this feature was fixed on FreeBSD the support proc would actually be updated, so I fail to see how this is significantly different. And the example you give is fundamentally different than my code. What I wrote is this: if { [is_svr4_target] } { set expected_result "PATTERN WHEN SUPPORTED" } else { set expected_result "PATTERN WHEN NOT SUPPORTED" } gdb_test "some command" $expected_result The difference here is that if a non-svr4 target is fixed then it will stop emitting "PATTERN WHEN NOT SUPPORTED" and will start emitting "PATTERN WHEN SUPPORTED". If the developer actually runs the complete testsuite then they will see a PASS -> FAIL for this test, which will force them to update the `if` condition (but see below). I tried to investigate if the test you quoted above could be made to work in the same way; i.e. on the unsupported path, actually run a test that confirms the feature is unsupported, which would have immediately identified when the feature started being supported, but I couldn't see how GDB would fail, most of the fork handling code appears to be generic, and targets that don't have specific overrides fallback to process_stratum_target, which doesn't care if we're following the parent or child. > >> >> Another option would be for me to just not add any test skipping right >> now. I know this will lead to the test failing for some targets as the >> new feature is only implemented for svr4 targets. Then, if someone on a >> failing target cares, they can add the missing feature. This approach >> feels a bit mean, I don't like adding failing tests for others, but it >> does draw attention to the problem. > > I think the best would be to just add a reasonable deny-list from > the get go. I suspect this is going to be a good enough starting point: > > proc supports_process_entry_point {} { > if windows || darwin > return 0 > > if is_svr4_target > return 1 # works even if remote, svr4 is handled on the host. > > if remote > return 0 # no RSP packet that gets us the info > > # Assume yes. > return 1 > } I do agree with you that having a 'supports_....' proc will be better than having to update the `if` condition within the test itself. If the supports proc ends up being used multiple times then we only need to update the one place and all the tests will be fixed. I'll follow the structure you propose here as I'd like to progress this patch. I'll post a v4 with the update soon. Thanks, Andrew