From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id +QflAbeXMWqhtQoAWB0awg (envelope-from ) for ; Tue, 16 Jun 2026 14:36:39 -0400 Received: by simark.ca (Postfix, from userid 112) id 033C51E098; Tue, 16 Jun 2026 14:36:39 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.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 3C9461E070 for ; Tue, 16 Jun 2026 14:36:38 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1613448F60F7 for ; Tue, 16 Jun 2026 18:36:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1613448F60F7 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) by sourceware.org (Postfix) with ESMTPS id 6633848F52CC for ; Tue, 16 Jun 2026 18:36:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6633848F52CC Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6633848F52CC Authentication-Results: sourceware.org; arc=none smtp.remote-ip=209.85.128.54 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1781634973; cv=none; b=eOyV4Z+gGRyVGmJzBkfxnpYYCSmYY2Bv91ZKZvZrLNmZc7SilwiCZJ9jWym7HRil5qQkgk1Od+tkALA6OJVtFlENvUvp9/vhKjysLPJdR/t00gZimys1FBaiLgP4M7l3AhTKQkrlB/wXXC/D6VFswROgq1ff4pA1XNcC53mCfmI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1781634973; c=relaxed/simple; bh=fxW6ZHq/7onpyZC65NJt9Mce4wAt6efN94QVsD06IoM=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=fMFcvw+mypckDna7WzgyJkADEyJuFipQpqt+tAioT3bKvRbO5ImxOhsNPuuzZ7hFvoPcxI6S8I3iuDwlLiB9EP3ZuuQRF1SefJGbS1yrrfFswlWnP6j7IhCM8wFBEZqGxcFK2EymryqhjwyfDzC99PNK9JKRhCtw/3oo2Dp+S6o= ARC-Authentication-Results: i=1; sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6633848F52CC Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-491609cdd8fso25956235e9.2 for ; Tue, 16 Jun 2026 11:36:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781634972; x=1782239772; h=content-transfer-encoding:in-reply-to:content-language:from :references:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hGvO17MfbiFedemFVNWpNtXplniwHIy40pcSizW4X3Y=; b=MaijxZ20u+svWQiRUvhKP+5pYFJ+1yn+zwTf/R4WHgSKO5/xWD3Z4oOzLET9JPuAyp +j/BL2LJpFubNYAJl+BXoGd8xtoBr7NS8nmjVVQkl2dXZhBO3rsJznZi4VmanMoXYZPF ILuMQKtaHvqV3anINhi8wZY094HJewXBTd4lwwKS7QMCDtnXQJ/NUG4Oo6Fwi1m5QEB8 YVKsMvpIGGN3VvrGFAEnjORdJUAXGlyC2VrjW8mrj1xNPb0/JSFap2YFIACbb6y5yBBi N7UYacUsm2LtLU3b2Rie6sNbbej90HJy7GDrS5GntCtI8hIjeNRKLn5Bk9JVuqwRukE/ RBJQ== X-Forwarded-Encrypted: i=1; AFNElJ/k8ybsihWITpVwqckDXXehaIEF3tjQpA18sOtFTGc5KPt6A2xbaSasT6xRJZvTBbEmNKbymbfbhcZBBQ==@sourceware.org X-Gm-Message-State: AOJu0YznbyL+X3zFyRE2BlbyjmVTO3lN4Tv1N4CD7fGCoCgcfp3pbTLX mrUfYMLUG0VSEg7tPw7bhsKxjrvByPjWRfdEFCPpOSg7xbhmTABHNErauBT/5g== X-Gm-Gg: Acq92OFGvtZyulRWtkNyhOlkp1Zkg21FzvSkZjXXWr32/gja1UITBMVQ6HtxLMJVguQ kzfBdABwuEPVWvZs1fFt6omGVNx+cU8KVbdGzp3bMMaKSYDS/O3h37I2UJJ0G62OSorDogahqdG wsVHJe08Nay6+jFy+A6hRbq1NvRzhPiq4znbC5EfpLkQ4tb+407j7gXBUReopxhoOMHcjAU89P5 djELWZypFC14hpP0VcMNxx9Kc149OfHvF0z208YR7vqq62XSmur3dyQW4xOux6YvUdB3/C3asha Y/OpU86rWjFJsSPFbYsiyVEKAbFLByo4Hk/UZufP0eLYrixZY5nql4PZ6D0r/3XvLtH4FaeKGFd eUIetnOL6Abd2sPfy0CuqsIYtJk6FdaH0j1B4+cFpoeRjaVTpdWOH+xzfDPyVUGkvZyF6qlahqs 2lfq0OFluYPKUUJxPgc+bLc9PHnrLrqJuQiyzFSEo0mZ0v0pe96I/ktlSI1+rLhtV1wA== X-Received: by 2002:a05:600c:24b:b0:490:c6c2:52 with SMTP id 5b1f17b1804b1-492333a1917mr10268945e9.3.1781634972171; Tue, 16 Jun 2026 11:36:12 -0700 (PDT) Received: from ?IPV6:2001:8a0:fae3:2600:3c50:6b74:6f0f:4555? ([2001:8a0:fae3:2600:3c50:6b74:6f0f:4555]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4922fa3a4easm100284585e9.3.2026.06.16.11.36.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Jun 2026 11:36:11 -0700 (PDT) Message-ID: Date: Tue, 16 Jun 2026 19:36:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCHv2 2/3] gdb: introduce program_space::get_entry_point_info function To: Andrew Burgess , gdb-patches@sourceware.org References: <41fe591d58ba010fa771e80ca674b61e30feef2f.1780942441.git.aburgess@redhat.com> <864cefb52d208dd8aac6b1b5f452cadad7546af8.1781214731.git.aburgess@redhat.com> <87fr2op04p.fsf@redhat.com> From: Pedro Alves Content-Language: en-US In-Reply-To: <87fr2op04p.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 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. > > 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 wonder if a better approach would to stick with my allow list, but add > an 'unsupported' call in the else block. Maybe someone on e.g. Windows, > will periodically look at tests that report 'unsupported' and see if > there is anything that could be done? If 'unsupported' is the wrong > type then I can use whatever you prefer. I don't think so. In my experience, people ignore/miss PASS -> UNSUPPORTED regressions, let alone looking for UNSUPPORTED results indicating tests they should/could enable. It is still good to issue an UNSUPPORTED, but I wouldn't make that the discovery mechanism. Pedro Alves > > I agree with your feedback on svr4 being wider than just Linux, I'll add > a helper function for `is_svr4_target` to lib/gdb.exp and then make use > of that, the svr4 list can then be improved over time. > > Thanks, > Andrew >