[PATCH v2] [gdb] Fix "value is not available" with debug frame

[PATCH v2] [gdb] Fix "value is not available" with debug frame

[Tom de Vries]

On arm-linux, with a started hello world, running "info frame" works fine, but
when I set debug frame to on, I run into:
...
(gdb) info frame
  ...
[frame] frame_unwind_register_value: exit
value is not available
(gdb)
...

The problem is here in frame_unwind_register_value:
...
          if (value->lazy ())
            gdb_printf (&debug_file, " lazy");
          else
            {
              int i;
              gdb::array_view<const gdb_byte> buf = value->contents ();
...
where we call value->contents () while !value->entirely_available ().

Fix this by checking value->entirely_available () and printing:
...
    [frame] frame_unwind_register_value:   -> register=91 unavailable
...

Tested on arm-linux.

PR gdb/31369
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31369
---
 gdb/frame.c                            |  2 +
 gdb/testsuite/gdb.base/debug-frame-2.c | 22 ++++++++++
 gdb/testsuite/gdb.base/debug-frame.c   | 25 +++++++++++
 gdb/testsuite/gdb.base/debug-frame.exp | 58 ++++++++++++++++++++++++++
 4 files changed, 107 insertions(+)
 create mode 100644 gdb/testsuite/gdb.base/debug-frame-2.c
 create mode 100644 gdb/testsuite/gdb.base/debug-frame.c
 create mode 100644 gdb/testsuite/gdb.base/debug-frame.exp

diff --git a/gdb/frame.c b/gdb/frame.c
index 72a34fcfedc..7060a2d00ec 100644
--- a/gdb/frame.c
+++ b/gdb/frame.c
@@ -1314,6 +1314,8 @@ frame_unwind_register_value (frame_info_ptr next_frame, int regnum)
 
 	  if (value->lazy ())
 	    gdb_printf (&debug_file, " lazy");
+	  else if (!value->entirely_available ())
+	    gdb_printf (&debug_file, " unavailable");
 	  else
 	    {
 	      int i;
diff --git a/gdb/testsuite/gdb.base/debug-frame-2.c b/gdb/testsuite/gdb.base/debug-frame-2.c
new file mode 100644
index 00000000000..571b1407374
--- /dev/null
+++ b/gdb/testsuite/gdb.base/debug-frame-2.c
@@ -0,0 +1,22 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+   Copyright 2024 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+void
+foo (void)
+{
+
+}
diff --git a/gdb/testsuite/gdb.base/debug-frame.c b/gdb/testsuite/gdb.base/debug-frame.c
new file mode 100644
index 00000000000..629c3097aaf
--- /dev/null
+++ b/gdb/testsuite/gdb.base/debug-frame.c
@@ -0,0 +1,25 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+   Copyright 2024 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+extern void foo (void);
+
+int
+main (void)
+{
+  foo ();
+  return 0;
+}
diff --git a/gdb/testsuite/gdb.base/debug-frame.exp b/gdb/testsuite/gdb.base/debug-frame.exp
new file mode 100644
index 00000000000..f00ca256266
--- /dev/null
+++ b/gdb/testsuite/gdb.base/debug-frame.exp
@@ -0,0 +1,58 @@
+# Copyright 2024 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# Test relies on checking gdb debug output. Do not run if gdb debug is
+# enabled as any debug will be redirected to the log.
+require !gdb_debug_enabled
+
+standard_testfile .c -2.c
+set srcfiles [list $srcfile $srcfile2]
+if {[prepare_for_testing "failed to prepare" $testfile $srcfiles]} {
+    return -1
+}
+
+if ![runto_main] {
+    return -1
+}
+
+# Redirect debug output to file.
+set logfile [host_standard_output_file gdb.txt]
+gdb_test_no_output "set logging file $logfile" \
+    "set logging file [file tail $logfile]"
+gdb_test_no_output "set logging debugredirect on"
+gdb_test "set logging enabled on"
+
+# Enable debug frame.
+gdb_test "set debug frame 1"
+
+# Check that calling info frame doesn't trigger an exception that escapes to
+# the CLI.
+set re_locals " Locals at \[^\r\n\]*"
+set re_regs1 " Saved registers:"
+set re_reg "\[^ \]+ at $hex"
+set re_regs2 "  $re_reg,( $re_reg,)*"
+set re_regs3 "  ${re_reg}(, $re_reg)*"
+
+set re1 $re_locals
+set re2 \
+    [multi_line \
+	 $re_locals\
+	 $re_regs1 \
+	 ($re_regs2\r\n)*$re_regs3]
+gdb_test "info frame" "\r\n($re1|$re2)"
+
+gdb_test_no_output "set debug frame 0"
+gdb_test "set logging enabled off"
+

base-commit: a16034bf6417dc2259fef43fd5bcc2dd1dac562f
-- 
2.35.3

Re: [PATCH v2] [gdb] Fix "value is not available" with debug frame

[Kevin Buettner]

Hi Tom,

On Tue, 13 Feb 2024 18:17:18 +0100
Tom de Vries <tdevries@suse.de> wrote:

> On arm-linux, with a started hello world, running "info frame" works fine, but
> when I set debug frame to on, I run into:
> ...
> (gdb) info frame
>   ...
> [frame] frame_unwind_register_value: exit
> value is not available
> (gdb)
> ...
> 
> The problem is here in frame_unwind_register_value:
> ...
>           if (value->lazy ())
>             gdb_printf (&debug_file, " lazy");
>           else
>             {
>               int i;
>               gdb::array_view<const gdb_byte> buf = value->contents ();
> ...
> where we call value->contents () while !value->entirely_available ().
> 
> Fix this by checking value->entirely_available () and printing:
> ...
>     [frame] frame_unwind_register_value:   -> register=91 unavailable
> ...
> 
> Tested on arm-linux.

The fix looks good to me.

I'm wondering about the test case though.  Is it the case that the
failure depends on debug info from a particular compiler (or compiler
version)?  If so, would it be possible to devise a test using the
DWARF assembler which would not be dependent on compiler output that
may change over time?

Kevin

Re: [PATCH v2] [gdb] Fix "value is not available" with debug frame

[Tom de Vries]

On 2/18/24 05:09, Kevin Buettner wrote:
> Hi Tom,
> 
> On Tue, 13 Feb 2024 18:17:18 +0100
> Tom de Vries <tdevries@suse.de> wrote:
> 
>> On arm-linux, with a started hello world, running "info frame" works fine, but
>> when I set debug frame to on, I run into:
>> ...
>> (gdb) info frame
>>    ...
>> [frame] frame_unwind_register_value: exit
>> value is not available
>> (gdb)
>> ...
>>
>> The problem is here in frame_unwind_register_value:
>> ...
>>            if (value->lazy ())
>>              gdb_printf (&debug_file, " lazy");
>>            else
>>              {
>>                int i;
>>                gdb::array_view<const gdb_byte> buf = value->contents ();
>> ...
>> where we call value->contents () while !value->entirely_available ().
>>
>> Fix this by checking value->entirely_available () and printing:
>> ...
>>      [frame] frame_unwind_register_value:   -> register=91 unavailable
>> ...
>>
>> Tested on arm-linux.
> 
> The fix looks good to me.
> 
> I'm wondering about the test case though.  Is it the case that the
> failure depends on debug info from a particular compiler (or compiler
> version)?  If so, would it be possible to devise a test using the
> DWARF assembler which would not be dependent on compiler output that
> may change over time?
> 

Hi Kevin,

thanks for the review.

This doesn't depend on debug info.  The test-case depends on a register 
being unavailable.  I don't know if or how we can reliably enforce this 
condition in a test-case.

To give some more detail, a minimal way to show the register as 
unavailable is:
...
$ gcc hello.c
$ gdb -q -batch a.out -ex start -ex 'p $tpidruro'
Temporary breakpoint 1 at 0x512

Temporary breakpoint 1, 0xaaaaa512 in main ()
$1 = <unavailable>
...

I'm not sure why it's unavailable.

It seems the register was added as part of some tls support for fbsd arm 
tdep.  It could be that support for the register is missing in linux arm 
tdep.

It also could be a kernel problem (used kernel is 4.4.190).

Or, something to do with the fact that I'm running a pinebook with 
64-bit kernel, 32-bit userland setup.

Luis, any comments on this?  Is this a bug, or a missing feature, or 
expected behaviour?

Thanks,
- Tom

> Kevin
> 

Re: [PATCH v2] [gdb] Fix "value is not available" with debug frame

[Tom de Vries]

On 2/18/24 14:30, Tom de Vries wrote:
> On 2/18/24 05:09, Kevin Buettner wrote:
>> Hi Tom,
>>
>> On Tue, 13 Feb 2024 18:17:18 +0100
>> Tom de Vries <tdevries@suse.de> wrote:
>>
>>> On arm-linux, with a started hello world, running "info frame" works 
>>> fine, but
>>> when I set debug frame to on, I run into:
>>> ...
>>> (gdb) info frame
>>>    ...
>>> [frame] frame_unwind_register_value: exit
>>> value is not available
>>> (gdb)
>>> ...
>>>
>>> The problem is here in frame_unwind_register_value:
>>> ...
>>>            if (value->lazy ())
>>>              gdb_printf (&debug_file, " lazy");
>>>            else
>>>              {
>>>                int i;
>>>                gdb::array_view<const gdb_byte> buf = value->contents ();
>>> ...
>>> where we call value->contents () while !value->entirely_available ().
>>>
>>> Fix this by checking value->entirely_available () and printing:
>>> ...
>>>      [frame] frame_unwind_register_value:   -> register=91 unavailable
>>> ...
>>>
>>> Tested on arm-linux.
>>
>> The fix looks good to me.
>>
>> I'm wondering about the test case though.  Is it the case that the
>> failure depends on debug info from a particular compiler (or compiler
>> version)?  If so, would it be possible to devise a test using the
>> DWARF assembler which would not be dependent on compiler output that
>> may change over time?
>>
> 
> Hi Kevin,
> 
> thanks for the review.
> 
> This doesn't depend on debug info.  The test-case depends on a register 
> being unavailable.  I don't know if or how we can reliably enforce this 
> condition in a test-case.
> 

Pushed.

Thanks,
- Tom

> To give some more detail, a minimal way to show the register as 
> unavailable is:
> ...
> $ gcc hello.c
> $ gdb -q -batch a.out -ex start -ex 'p $tpidruro'
> Temporary breakpoint 1 at 0x512
> 
> Temporary breakpoint 1, 0xaaaaa512 in main ()
> $1 = <unavailable>
> ...
> 
> I'm not sure why it's unavailable.
> 
> It seems the register was added as part of some tls support for fbsd arm 
> tdep.  It could be that support for the register is missing in linux arm 
> tdep.
> 
> It also could be a kernel problem (used kernel is 4.4.190).
> 
> Or, something to do with the fact that I'm running a pinebook with 
> 64-bit kernel, 32-bit userland setup.
> 
> Luis, any comments on this?  Is this a bug, or a missing feature, or 
> expected behaviour?
> 
> Thanks,
> - Tom
> 
>> Kevin
>>
> 

Re: [PATCH v2] [gdb] Fix "value is not available" with debug frame

[Thiago Jung Bauermann]

Tom de Vries <tdevries@suse.de> writes:
> This doesn't depend on debug info.  The test-case depends on a register being unavailable.
> I don't know if or how we can reliably enforce this condition in a test-case.
>
> To give some more detail, a minimal way to show the register as unavailable is:
> ...
> $ gcc hello.c
> $ gdb -q -batch a.out -ex start -ex 'p $tpidruro'
> Temporary breakpoint 1 at 0x512
>
> Temporary breakpoint 1, 0xaaaaa512 in main ()
> $1 = <unavailable>
> ...
>
> I'm not sure why it's unavailable.
>
> It seems the register was added as part of some tls support for fbsd arm tdep.  It could
> be that support for the register is missing in linux arm tdep.
>
> It also could be a kernel problem (used kernel is 4.4.190).

I did a bit of digging today and the $tpidruro register isn't available
via ptrace in the 32-bit Linux kernel, but it is available for an
aarch32 program running under an arm64 Linux kernel via the ptrace
compat interface.

Support for this isn't implemented in GDB however, so at least for now
IMHO it makes sense to disable the org.gnu.gdb.arm.tls feature in
arm-linux and arm-netbsd (which from a quick look at arm-netbsd-nat.c
also doesn't seem to support accessing $tpidruro either).

I'm testing a patch that does this and I'll post it if there are no
regressions.

-- 
Thiago

Re: [PATCH v2] [gdb] Fix "value is not available" with debug frame

[Simon Marchi]

On 2/26/24 17:34, Thiago Jung Bauermann wrote:
> 
> Tom de Vries <tdevries@suse.de> writes:
>> This doesn't depend on debug info.  The test-case depends on a register being unavailable.
>> I don't know if or how we can reliably enforce this condition in a test-case.
>>
>> To give some more detail, a minimal way to show the register as unavailable is:
>> ...
>> $ gcc hello.c
>> $ gdb -q -batch a.out -ex start -ex 'p $tpidruro'
>> Temporary breakpoint 1 at 0x512
>>
>> Temporary breakpoint 1, 0xaaaaa512 in main ()
>> $1 = <unavailable>
>> ...
>>
>> I'm not sure why it's unavailable.
>>
>> It seems the register was added as part of some tls support for fbsd arm tdep.  It could
>> be that support for the register is missing in linux arm tdep.
>>
>> It also could be a kernel problem (used kernel is 4.4.190).
> 
> I did a bit of digging today and the $tpidruro register isn't available
> via ptrace in the 32-bit Linux kernel, but it is available for an
> aarch32 program running under an arm64 Linux kernel via the ptrace
> compat interface.
> 
> Support for this isn't implemented in GDB however, so at least for now
> IMHO it makes sense to disable the org.gnu.gdb.arm.tls feature in
> arm-linux and arm-netbsd (which from a quick look at arm-netbsd-nat.c
> also doesn't seem to support accessing $tpidruro either).
> 
> I'm testing a patch that does this and I'll post it if there are no
> regressions.

Thanks, I think that would make sense.

The only time we should be seeing some "unavailable" registers or memory
is in the context of tracepoints, for things that are not collected.
Seeing an unavailable register here is a sign that something is not
right.

Simon

Re: [PATCH v2] [gdb] Fix "value is not available" with debug frame

[Tom de Vries]

On 2/26/24 23:41, Simon Marchi wrote:
> On 2/26/24 17:34, Thiago Jung Bauermann wrote:
>>
>> Tom de Vries <tdevries@suse.de> writes:
>>> This doesn't depend on debug info.  The test-case depends on a register being unavailable.
>>> I don't know if or how we can reliably enforce this condition in a test-case.
>>>
>>> To give some more detail, a minimal way to show the register as unavailable is:
>>> ...
>>> $ gcc hello.c
>>> $ gdb -q -batch a.out -ex start -ex 'p $tpidruro'
>>> Temporary breakpoint 1 at 0x512
>>>
>>> Temporary breakpoint 1, 0xaaaaa512 in main ()
>>> $1 = <unavailable>
>>> ...
>>>
>>> I'm not sure why it's unavailable.
>>>
>>> It seems the register was added as part of some tls support for fbsd arm tdep.  It could
>>> be that support for the register is missing in linux arm tdep.
>>>
>>> It also could be a kernel problem (used kernel is 4.4.190).
>>
>> I did a bit of digging today and the $tpidruro register isn't available
>> via ptrace in the 32-bit Linux kernel, but it is available for an
>> aarch32 program running under an arm64 Linux kernel via the ptrace
>> compat interface.
>>
>> Support for this isn't implemented in GDB however, so at least for now
>> IMHO it makes sense to disable the org.gnu.gdb.arm.tls feature in
>> arm-linux and arm-netbsd (which from a quick look at arm-netbsd-nat.c
>> also doesn't seem to support accessing $tpidruro either).
>>
>> I'm testing a patch that does this and I'll post it if there are no
>> regressions.
> 
> Thanks, I think that would make sense.
> 
> The only time we should be seeing some "unavailable" registers or memory
> is in the context of tracepoints, for things that are not collected.
> Seeing an unavailable register here is a sign that something is not
> right.

In that case, I've filed a PR ( 
https://sourceware.org/bugzilla/show_bug.cgi?id=31418 ) to track this 
problem.

Thanks,
- Tom

Re: [PATCH v2] [gdb] Fix "value is not available" with debug frame

[Luis Machado]

On 2/18/24 13:30, Tom de Vries wrote:
> On 2/18/24 05:09, Kevin Buettner wrote:
>> Hi Tom,
>>
>> On Tue, 13 Feb 2024 18:17:18 +0100
>> Tom de Vries <tdevries@suse.de> wrote:
>>
>>> On arm-linux, with a started hello world, running "info frame" works fine, but
>>> when I set debug frame to on, I run into:
>>> ...
>>> (gdb) info frame
>>>    ...
>>> [frame] frame_unwind_register_value: exit
>>> value is not available
>>> (gdb)
>>> ...
>>>
>>> The problem is here in frame_unwind_register_value:
>>> ...
>>>            if (value->lazy ())
>>>              gdb_printf (&debug_file, " lazy");
>>>            else
>>>              {
>>>                int i;
>>>                gdb::array_view<const gdb_byte> buf = value->contents ();
>>> ...
>>> where we call value->contents () while !value->entirely_available ().
>>>
>>> Fix this by checking value->entirely_available () and printing:
>>> ...
>>>      [frame] frame_unwind_register_value:   -> register=91 unavailable
>>> ...
>>>
>>> Tested on arm-linux.
>>
>> The fix looks good to me.
>>
>> I'm wondering about the test case though.  Is it the case that the
>> failure depends on debug info from a particular compiler (or compiler
>> version)?  If so, would it be possible to devise a test using the
>> DWARF assembler which would not be dependent on compiler output that
>> may change over time?
>>
> 
> Hi Kevin,
> 
> thanks for the review.
> 
> This doesn't depend on debug info.  The test-case depends on a register being unavailable.  I don't know if or how we can reliably enforce this condition in a test-case.
> 
> To give some more detail, a minimal way to show the register as unavailable is:
> ...
> $ gcc hello.c
> $ gdb -q -batch a.out -ex start -ex 'p $tpidruro'
> Temporary breakpoint 1 at 0x512
> 
> Temporary breakpoint 1, 0xaaaaa512 in main ()
> $1 = <unavailable>
> ...
> 
> I'm not sure why it's unavailable.
> 
> It seems the register was added as part of some tls support for fbsd arm tdep.  It could be that support for the register is missing in linux arm tdep.
> 
> It also could be a kernel problem (used kernel is 4.4.190).
> 
> Or, something to do with the fact that I'm running a pinebook with 64-bit kernel, 32-bit userland setup.
> 
> Luis, any comments on this?  Is this a bug, or a missing feature, or expected behaviour?
> 
> Thanks,
> - Tom
> 
>> Kevin
>>
> 

Hi Tom,

I was out on time off. It looks like Thiago addressed this in a separate thread, is that right?

Re: [PATCH v2] [gdb] Fix "value is not available" with debug frame

[Tom de Vries]

On 3/4/24 16:25, Luis Machado wrote:
> On 2/18/24 13:30, Tom de Vries wrote:
>> On 2/18/24 05:09, Kevin Buettner wrote:
>>> Hi Tom,
>>>
>>> On Tue, 13 Feb 2024 18:17:18 +0100
>>> Tom de Vries <tdevries@suse.de> wrote:
>>>
>>>> On arm-linux, with a started hello world, running "info frame" works fine, but
>>>> when I set debug frame to on, I run into:
>>>> ...
>>>> (gdb) info frame
>>>>     ...
>>>> [frame] frame_unwind_register_value: exit
>>>> value is not available
>>>> (gdb)
>>>> ...
>>>>
>>>> The problem is here in frame_unwind_register_value:
>>>> ...
>>>>             if (value->lazy ())
>>>>               gdb_printf (&debug_file, " lazy");
>>>>             else
>>>>               {
>>>>                 int i;
>>>>                 gdb::array_view<const gdb_byte> buf = value->contents ();
>>>> ...
>>>> where we call value->contents () while !value->entirely_available ().
>>>>
>>>> Fix this by checking value->entirely_available () and printing:
>>>> ...
>>>>       [frame] frame_unwind_register_value:   -> register=91 unavailable
>>>> ...
>>>>
>>>> Tested on arm-linux.
>>>
>>> The fix looks good to me.
>>>
>>> I'm wondering about the test case though.  Is it the case that the
>>> failure depends on debug info from a particular compiler (or compiler
>>> version)?  If so, would it be possible to devise a test using the
>>> DWARF assembler which would not be dependent on compiler output that
>>> may change over time?
>>>
>>
>> Hi Kevin,
>>
>> thanks for the review.
>>
>> This doesn't depend on debug info.  The test-case depends on a register being unavailable.  I don't know if or how we can reliably enforce this condition in a test-case.
>>
>> To give some more detail, a minimal way to show the register as unavailable is:
>> ...
>> $ gcc hello.c
>> $ gdb -q -batch a.out -ex start -ex 'p $tpidruro'
>> Temporary breakpoint 1 at 0x512
>>
>> Temporary breakpoint 1, 0xaaaaa512 in main ()
>> $1 = <unavailable>
>> ...
>>
>> I'm not sure why it's unavailable.
>>
>> It seems the register was added as part of some tls support for fbsd arm tdep.  It could be that support for the register is missing in linux arm tdep.
>>
>> It also could be a kernel problem (used kernel is 4.4.190).
>>
>> Or, something to do with the fact that I'm running a pinebook with 64-bit kernel, 32-bit userland setup.
>>
>> Luis, any comments on this?  Is this a bug, or a missing feature, or expected behaviour?
>>
>> Thanks,
>> - Tom
>>
>>> Kevin
>>>
>>
> 
> Hi Tom,
> 
> I was out on time off. It looks like Thiago addressed this in a separate thread, is that right?

Hi Luis,

welcome back :)

Thiago addressed removing the "<unavailable>" register.

I took the opportunity of having an "<unavailable>" register available 
to improve gdb behaviour in presence of such a register.

This patch is an example of that, as well as 
https://sourceware.org/pipermail/gdb-patches/2024-March/206965.html .

Thanks,
- Tom