Re: [PATCH] gdb/Windows testsuite: Avoid "bad" words in exe names

[Andrew Burgess <aburgess@redhat.com>]

Pedro Alves <pedro@palves.net> 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 <aburgess@redhat.com>

Thanks,
Andrew