gdb/testsuite: XFAIL some gdb.base/fileio.exp
Checks
| Context |
Check |
Description |
| linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 |
success
|
Testing passed
|
| linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 |
success
|
Testing passed
|
| linaro-tcwg-bot/tcwg_gdb_build--master-arm |
success
|
Testing passed
|
| linaro-tcwg-bot/tcwg_gdb_check--master-arm |
success
|
Testing passed
|
Commit Message
Some gdb.base/fileio.exp tests expect the inferior to not have write
access to some files. If the test is being run as root, this is never
possible. This commit adds a way to identify if the user is root and
xfails the tests that expect no write access.
---
gdb/testsuite/gdb.base/fileio.exp | 9 ++++++++-
gdb/testsuite/lib/gdb.exp | 11 +++++++++++
2 files changed, 19 insertions(+), 1 deletion(-)
Comments
Hi Guinevere,
I am not a big fan of the idea of running the testcases as root… but I
guess this is what you have when running within a container.
> +# Return 1 if the test is being run as root, 0 otherwise
> +
> +gdb_caching_proc root_user {} {
> + # ID outputs to stdout, we have to use exec to capture it here
> + set user [exec id]
Shouldn't it be `[remote_exec target]` instead? You are interested in
who will end up running the test executable, which can be different from
who runs `runtest` locally. I am not entirely sure if it should be
`host` or `target`. I would think `target`, but the testcase does use
`host`, which seems odd to me.
Also, what happens if the underlying filesystem is for example a NFS
mount? I am not sure being root will change what unlink can do, but I
have not tested. Maybe it is not worth trying to figure out all setups,
if it comes up one can always adjust the test.
Best,
Lancelot.
> +
> + regexp -all ".*uid=(\[0-9\]+).*" $user user uid
> +
> + return [expr $uid == 0]
> +}
> +
> # Always load compatibility stuff.
> load_lib future.exp
> --
> 2.41.0
>
On 11/08/2023 15:19, Lancelot SIX wrote:
> Hi Guinevere,
>
> I am not a big fan of the idea of running the testcases as root… but I
> guess this is what you have when running within a container.
yeah, this is focused on VM/containers for testing infrastructure.
>
>> +# Return 1 if the test is being run as root, 0 otherwise
>> +
>> +gdb_caching_proc root_user {} {
>> + # ID outputs to stdout, we have to use exec to capture it here
>> + set user [exec id]
> Shouldn't it be `[remote_exec target]` instead? You are interested in
> who will end up running the test executable, which can be different from
> who runs `runtest` locally. I am not entirely sure if it should be
> `host` or `target`. I would think `target`, but the testcase does use
> `host`, which seems odd to me.
Thank you. I always forget about how the remote stuff works, but I think
you are correct, it does make more sense to use remote_exec, because the
test failures are based on if the underlying program can access it or
not. I'll fix this in v2.
>
> Also, what happens if the underlying filesystem is for example a NFS
> mount? I am not sure being root will change what unlink can do, but I
> have not tested. Maybe it is not worth trying to figure out all setups,
> if it comes up one can always adjust the test.
I think you're right, being root wouldn't let you access those, but I am
not sure many people are testing GDB with an NFS mounted build directory
inside a VM/container. I think setups like that can be dealt with if
they appear.
@@ -17,7 +17,6 @@
require {!target_info exists gdb,nofileio}
-
standard_testfile
if {[is_remote host]} {
@@ -75,6 +74,10 @@ gdb_test "continue" ".*" ""
catch "system \"chmod -f -w [standard_output_file nowrt.fileio.test]\""
+# If the user is root, we will always have write permission
+if { [root_user] } {
+ setup_xfail *-*
+}
gdb_test continue \
"Continuing\\..*open 5:.*EACCES$stop_msg" \
"Open for write but no write permission returns EACCES"
@@ -240,6 +243,10 @@ gdb_test continue \
if [ishost *cygwin*] {
setup_xfail "*-*-*"
}
+# If the user is root, we will always have write permission
+if { [root_user] } {
+ setup_xfail *-*
+}
gdb_test continue \
"Continuing\\..*unlink 2:.*EACCES$stop_msg" \
"Unlinking a file in a directory w/o write access returns EACCES"
@@ -9952,5 +9952,16 @@ proc have_host_locale { locale } {
return [expr $idx != -1]
}
+# Return 1 if the test is being run as root, 0 otherwise
+
+gdb_caching_proc root_user {} {
+ # ID outputs to stdout, we have to use exec to capture it here
+ set user [exec id]
+
+ regexp -all ".*uid=(\[0-9\]+).*" $user user uid
+
+ return [expr $uid == 0]
+}
+
# Always load compatibility stuff.
load_lib future.exp