From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 4c9iM9IEUWp51QEAWB0awg (envelope-from ) for ; Fri, 10 Jul 2026 10:42:26 -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=ggeNxsJg; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id C04231E070; Fri, 10 Jul 2026 10:42:26 -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 3F43B1E070 for ; Fri, 10 Jul 2026 10:42:26 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 451324BA23DC for ; Fri, 10 Jul 2026 14:42:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 451324BA23DC 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=ggeNxsJg 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 805AA4BA2E0A for ; Fri, 10 Jul 2026 14:42:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 805AA4BA2E0A 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 805AA4BA2E0A 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=1783694520; cv=none; b=nqcnDqfuNDiPDLI6znzLx4GDaYlogLpjJcki2VEYhsvxOeNMzmyvL1klV+7WJx+jD8n7rEwwv1ONsdXz2aoME5Id0hyMgPLYv9+17pW11AEHWd53AhrKBII8V3pB+zbRLhOL+H17B7cKVluLQqhDyf+kvoHFAlaRzJB4tsqGbLs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1783694520; c=relaxed/simple; bh=L0fg0bKdOpHvFDq3WW1R00rhq1Yv16QpCJp5MdaNRuE=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=XzfThKeZZoFktU9tG//a/3VcgyMeQxd8loTBj035oPFDIzoUN2y63tQFjMOdXdVQzXRH8ZFC+PDCaRLhNr9nVbFn/FaWhVW1WZU6kQUFuD2FsGJNDqb44zltDrvkZpsXU6dHvn4CbZYkWNW7///T37pMUcy2HsHHwdlF1spPpL8= 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=ggeNxsJg DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 805AA4BA2E0A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1783694520; 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=iYBFw+Dk/dXzbzazn8oBmCPzL7PTOx1K/9iud6njSRY=; b=ggeNxsJgdUlf1nTIrGWCCLZ13XkeI4bY5fXVE3bVvq8FGChnIejDJPp82+K5tuU5z5fp3O vwK0jhY+K1D5vw4PuFw3YFJQENzMDXCx1b2tJdF21TvwFcx8ggsZRhMuyPRGjErdaPUH+C CX/F0Yl3UIZMCleEyUGoaGTXulSpr/0= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-85-mcwq_ZvCMUWlj0ehBn1MAw-1; Fri, 10 Jul 2026 10:41:58 -0400 X-MC-Unique: mcwq_ZvCMUWlj0ehBn1MAw-1 X-Mimecast-MFC-AGG-ID: mcwq_ZvCMUWlj0ehBn1MAw_1783694517 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-493bab443f7so6521585e9.0 for ; Fri, 10 Jul 2026 07:41:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783694517; x=1784299317; h=content-type: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:content-type; bh=iYBFw+Dk/dXzbzazn8oBmCPzL7PTOx1K/9iud6njSRY=; b=aJUtPChjvcdHQP3zdPK41xE2VS3eUhxHFAWy94fitLTHCtD+TxEhClP28jDd2lvFK4 Te4gdDZHQOY0vWHmalAIDpCVFx59aKCyJISC0PHuBpQ3WkRbDQ0vmLjlWkGm1G9TVFAj 7TnBij7dIrpeW9pbdRl6FWmR7egqgZ1JYjdsJ+LP11t6WmYq6rgXre6Fmy5ejm91Fp3P AY+GZ3lOccLDS9Q9dtirpAazL7o9h/eukMkAzVbZ7ihrAbQIKtJGe62FVEzz9LBkLsml iQa6e4ro1Bqk1XAaARuwpKW0M+BFIsMVy4V6rduRd4+UHK15a0LYX8KJ5abw/SSJwdOt 5iAQ== X-Forwarded-Encrypted: i=1; AHgh+RoSrVUWk05QZGbyW7yEAQnZh3Jfl31sjOTexy8VwJMPAyWv/a8AqKCluwc+74TUbAFDP0sgqreESlaGvA==@sourceware.org X-Gm-Message-State: AOJu0YzGd6Lw4wKYhHOyBRI1HVzEvWGkHybsoOzwb1s7FTbuUMLsVyha lkp3tA9Pgk9/9yZ45uq265LwjMs4IRA03LKwBd7fqdKrWWcEwGFj1HynUVsI8NlfpaBNSqELvle RKv/PoChOUT6bpRpXWB7mGr8oruazGJRbrL0DL6jW21bTm6Sl71LklXh+PdRlRgOv6V5Fx4Q= X-Gm-Gg: AfdE7cn0LyJBYmJWvbUjGdWneGmhKOYoLfWSdpDaQ1+m6IQ80Be8ii/ue+spm0pHppf 8Or20MPtKkuAegJkxlg/L+ZbVreXX32Kh6ES9cnqbmnU9jMxWH4aBG2BAgFfyh+s49Pr+O4eL7C nh5VwDTavwpViUTEPwAo2DaifKGo108cjKQK8ccAYQsbEk7OfznN5QGxJe6kO660g51ysp++09D nYggO00L3tJXkAcMFQs+O83PW+MH/sYc/+S1fwS2pX37gn4MPR138nBxBqj7ucKGCJLnAJIPB3L WTrVAsv/4ziPLU9Man3wymScYOXR6MnjmURua9JERjIemGKLQ7j8SzHS0Y/r9jVrhZwPI3MH60U XITbI8Sc= X-Received: by 2002:a05:600c:3495:b0:493:ecf5:89fd with SMTP id 5b1f17b1804b1-493f2b4a78bmr37603865e9.17.1783694517432; Fri, 10 Jul 2026 07:41:57 -0700 (PDT) X-Received: by 2002:a05:600c:3495:b0:493:ecf5:89fd with SMTP id 5b1f17b1804b1-493f2b4a78bmr37603585e9.17.1783694516978; Fri, 10 Jul 2026 07:41:56 -0700 (PDT) Received: from localhost ([31.111.209.233]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-493f2d88698sm66154905e9.1.2026.07.10.07.41.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jul 2026 07:41:56 -0700 (PDT) From: Andrew Burgess To: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [PATCH] gdb/Windows testsuite: Avoid "bad" words in exe names In-Reply-To: <20260709174351.431907-1-pedro@palves.net> References: <20260709174351.431907-1-pedro@palves.net> Date: Fri, 10 Jul 2026 15:41:55 +0100 Message-ID: <874ii6gb4c.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: tbG-yFhQIQmxhngbZQYtN-UTJ392st0Gufs1p2lRAco_1783694517 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: > Running gdb.base/execl-update-breakpoints.exp on Windows 11 shows this > FAIL: > > (gdb) run > Starting program: .../gdb.base/execl-update-breakpoints/execl-update-breakpoints1.exe > Error creating process .../gdb.base/execl-update-breakpoints/execl-update-breakpoints1.exe (error 740): The requested operation requires elevation. > (gdb) FAIL: gdb.base/execl-update-breakpoints.exp: runto: run to main > > Error 740 is ERROR_ELEVATION_REQUIRED. > > Turns out that Windows has an "installer detection" heuristic that > refuses to launch executables whose filename contains keywords like > "update", "setup", and "install" without elevation (admin rights), > unless the PE embeds a manifest declaring > requestedExecutionLevel="asInvoker". > > I found some older Microsoft documentation claiming that the heuristic > only applies to 32-bit binaries, but what I observe is that: > > - It triggers with 64-bit PEs on current Windows. > > And also: > > - Matches the word (e.g. "update") as a substring anywhere in the > filename (not just as a prefix). > > - Is not drive-dependent. I thought moving the process to a dev > drive might suppress the check, but it does not. > > I saw this problem first in a downstream ROCgdb testcase, and there I > fixed it by adjusting the name of that particular testcase. > > Since this is the second case I'm seeing this already, I thought I'd > fix it in a more general way this time, one that avoids adding the > same explanatory comment to several testcases. > > Fix it by making standard_testfile tweak the resulting "binfile" > output variable to avoid the "bad" words, on Windows. This way, in > theory we only need to handle this once, in a central place. > > Change-Id: I93c7d733fb8870b4ec6ff97ca59013211b362061 > --- > gdb/testsuite/lib/gdb.exp | 24 +++++++++++++++++++++++- > 1 file changed, 23 insertions(+), 1 deletion(-) > > diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp > index 8eeaf2fc8e6..1201b615ee6 100644 > --- a/gdb/testsuite/lib/gdb.exp > +++ b/gdb/testsuite/lib/gdb.exp > @@ -4130,6 +4130,12 @@ proc is_aarch64_target {} { > return [expr {![is_aarch32_target]}] > } > > +# Return true if the target is Windows-based. > + > +proc is_windows_based_target {} { > + return [expr {[istarget *-*-cygwin*] || [istarget *-*-mingw*]}] > +} > + > # Return 1 if displaced stepping is supported on target, otherwise, return 0. > proc support_displaced_stepping {} { > > @@ -8414,7 +8420,23 @@ proc standard_testfile {args} { > global testfile binfile > > set testfile $gdb_test_file_name > - set binfile [standard_output_file ${testfile}] > + > + if {[is_windows_based_target]} { > + # Windows' installer detection heuristic refuses to launch > + # executables whose name contains the following words without > + # elevation, failing with ERROR_ELEVATION_REQUIRED (740). > + # > + # Map of WORD => REPLACEMENT. > + set word_map { > + "update" "up_date" > + "setup" "set_up" > + "install" "inst_all" > + } > + set binfile_basename [string map $word_map $testfile] > + } else { > + set binfile_basename $testfile > + } > + set binfile [standard_output_file ${binfile_basename}] The change looks fine, but I wonder if we should factor this mapping into a helper function? There are tests that setup multiple executables, and a common pattern is to call standard_output_file rather than building the names from BINFILE. It might be helpful if we had a helper proc that we could call if needed in these cases. Or maybe standard_output_file could use parse_some_args to allow something like: set binfile [standard_output_file -exec ${binfile_basename}] with '-exec' being a flag to indicate we're creating an executable, in which ase BINFILE_BASENAME would have the string mapping applied? Just a thought though, we can always tweak things later if you'd rather stick with this. Reviewed-By: Andrew Burgess Thanks, Andrew