[Bug testsuite/33345] [gdb/testsuite] FAIL: gdb.dap/scopes.exp: fetch all registers success

[aburgess at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=33345

Andrew Burgess <aburgess at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aburgess at redhat dot com

--- Comment #8 from Andrew Burgess <aburgess at redhat dot com> ---
(In reply to Schimpe, Christina from comment #6)
> Hi Tom,
> 
> on my system with SUSE Linux Enterprise Server 15 SP6 I have a similar
> setup, e.g.
> linux kernel 6.4, gcc 7.5 and glibc 2.38.
> 
> I wasn't aware that such setups exist actually.
> 
> With glibc < 2.39 we cannot enable CET shadow stack automatically using
> -fcf-protection + glibc. 
> 
> We can enable it using inline enablement, similar to the kernel selftests:
> 
> https://github.com/torvalds/linux/blob/master/tools/testing/selftests/x86/
> test_shadow_stack.c#L86
> 
> Alternatively, we can try to make the test accept unavailable registers.
> 
> What do you think would be better?

I don't have access to a machine with SSP support, but I would be tempted to
investigate why the test fails when the register is unavailable.

Looking at the commit message for 63b862be762e1e6e7ce667c6b4a1a3dd79939bf4 we
see this as the explanation for the gdb.dap/scopes.exp failure:

    {"request_seq": 12, "type": "response", "command": "variables", "success":
false, "message": "value is not available", "seq": 25}FAIL: gdb.dap/scopes.exp:
fetch all registers success
    ERROR: tcl error sourcing /tmp/gdb/testsuite/gdb.dap/scopes.exp.

Notice the 'value is not available' message.  This isn't something I'd
necessarily expect to see from an attempt to read an unavailable register,
indeed, this message is from value_assign.

Further, if I hack amd64_linux_nat_target::fetch_registers so tht the fs_base
register is always unavailable, like this:

diff --git i/gdb/amd64-linux-nat.c w/gdb/amd64-linux-nat.c
index 4b23fd9de53..4e6593b9356 100644
--- i/gdb/amd64-linux-nat.c
+++ w/gdb/amd64-linux-nat.c
@@ -230,6 +230,8 @@ amd64_linux_nat_target::fetch_registers (struct regcache
*regcache, int regnum)
        perror_with_name (_("Couldn't get registers"));

       amd64_supply_native_gregset (regcache, &regs, -1);
+
+      regcache->raw_supply (AMD64_FSBASE_REGNUM, NULL);
       if (regnum != -1)
        return;
     }

then the test passes just find, and I can see the <unavailable> value mentioned
in the test output.

So, for me, I'd like to have a better understanding of what triggers the error
about the register being unavailable.  It might be that there's a bug elsewhere
in the DAP code that triggers this issue maybe?

-- 
You are receiving this mail because:
You are on the CC list for the bug.