Re: [PATCH] gdb/testsuite: XFAIL some gdb.base/fileio.exp

[Guinevere Larsen <blarsen@redhat.com>]

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.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

>
> 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
>>