[Bug exp/31005] New: "Cannot access memory at address 0x0" for inlined function argument

[Bug exp/31005] New: "Cannot access memory at address 0x0" for inlined function argument

[tpzker at thepuzzlemaker dot info]

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

            Bug ID: 31005
           Summary: "Cannot access memory at address 0x0" for inlined
                    function argument
           Product: gdb
           Version: 13.1
            Status: UNCONFIRMED
          Severity: minor
          Priority: P2
         Component: exp
          Assignee: unassigned at sourceware dot org
          Reporter: tpzker at thepuzzlemaker dot info
  Target Milestone: ---

Created attachment 15199
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15199&action=edit
riscv64gc-unknown-none-elf binary with debuginfo

I'd like to apologize in advance that I don't have an MCVE for this.

Running the attached binary causes some issues with inlined function arguments.

This binary is for my own kernel I'm developing for learning purposes, but can
be started with QEMU linux and the bug shows up before it crashes due to
invalid syscall args.

Note that due to #29735 this will crash if you use any extension e.g. GEF that
will run `info args`

- Download the attached binary, and run `qemu-riscv64 -g 1234
userspace_testing`
- Run in a separate tty `gdb userspace_testing`
- Run `target remote :1234`
- Run `si` twice
- Observe the following:
```
rille::capability::RemoteCaptr<rille::capability::Captbl>::copy_deep<rille::capability::Captbl>
(self=..., from_index=<error reading variable: Cannot access memory at address
0x0>, into=..., 
    into_index=<error reading variable: Cannot access memory at address 0x0>)
at rille/src/capability/mod.rs:340
340            syscalls::captbl::copy_deep(
```

This is invalid, as `from_index` is *not* a pointer of any sort, just an
integer value in one of the `a` registers (though not yet loaded at this
point).

When looking at the DWARF info (with llvm-dwarfdump) it shows the following:
```
0x0000135f:         DW_TAG_inlined_subroutine
                      DW_AT_abstract_origin     (0x0000000000001b84
"rille::capability::RemoteCaptr<rille::capability::Captbl>::copy_deep")
                      DW_AT_low_pc      (0x00000000000120da)
                      DW_AT_high_pc     (0x00000000000120f2)
                      DW_AT_call_file  
("/home/wren/Code/RISCV/river/user/userspace_testing/src/main.rs")
                      DW_AT_call_line   (15)
                      DW_AT_call_column (0x15)

0x00001373:           DW_TAG_formal_parameter
                        DW_AT_location  (0x00000330: 
                           [0x00000000000120d6, 0x00000000000120f2):
DW_OP_lit0, DW_OP_stack_value, DW_OP_piece 0x8, DW_OP_lit1, DW_OP_stack_value,
DW_OP_piece 0x8)
                        DW_AT_abstract_origin   (0x0000000000001b93 "self")

0x0000137c:           DW_TAG_formal_parameter
                        DW_AT_const_value       (1)
                        DW_AT_abstract_origin   (0x0000000000001b9f
"from_index")

0x00001382:           DW_TAG_formal_parameter
                        DW_AT_location  (0x0000036a: 
                           [0x00000000000120d6, 0x00000000000120f2):
DW_OP_lit0, DW_OP_stack_value, DW_OP_piece 0x8, DW_OP_lit1, DW_OP_stack_value,
DW_OP_piece 0x8)
                        DW_AT_abstract_origin   (0x0000000000001bab "into")

0x0000138b:           DW_TAG_formal_parameter
                        DW_AT_const_value       (2)
                        DW_AT_abstract_origin   (0x0000000000001bb7
"into_index")
```

When debugging, I found that this issue stemmed from looking at the
discriminant value in `compute_variant_field_inner`. This ultimately was called
(skipping a few frames for the sake of brevity, they aren't important here) in
this portion of code:
```
 582     case LOC_CONST:
 583       if (is_dynamic_type (type))
 584         {
 585           /* Value is a constant byte-sequence and needs no memory access.
 */
 586           type = resolve_dynamic_type (type, {}, /* Unused address.  */
0);
 587         }
```
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/findvar.c;h=02d498d8c587616a52613fbc3b0ee749eff122ba;hb=662243de0e14a4945555a480dca33c0e677976eb#l582

With `valaddr` in `resolve_dynamic_type`'s `addrstack` empty, and a null
address, it tries to read the memory at `0x0` to resolve the discriminant type.
This is incorrect as the discriminant field could be resolved from the constant
value in the DWARF debuginfo.

I created a simple patch that fixes just this case, but may not fix others. I
will attach it. Feel free to change and extend on this, as long as I am a
co-author on the final patch if accepted.

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

[Bug exp/31005] "Cannot access memory at address 0x0" for inlined function argument

[tpzker at thepuzzlemaker dot info]

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

--- Comment #1 from The Puzzlemaker <tpzker at thepuzzlemaker dot info> ---
Created attachment 15200
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15200&action=edit
Simple, but hacky patch to fix this

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

[Bug exp/31005] "Cannot access memory at address 0x0" for inlined function argument

[tpzker at thepuzzlemaker dot info]

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

The Puzzlemaker <tpzker at thepuzzlemaker dot info> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tpzker at thepuzzlemaker dot info
             Target|                            |riscv64-elf

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

[Bug exp/31005] "Cannot access memory at address 0x0" for inlined function argument

[tpzker at thepuzzlemaker dot info]

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

--- Comment #2 from The Puzzlemaker <tpzker at thepuzzlemaker dot info> ---
I have tried this as of 934a14fd6b60626512b5a9c61d25df11e073fb0b on the 14.x
git and it still occurs.

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

[Bug exp/31005] "Cannot access memory at address 0x0" for inlined function argument

[sam at gentoo dot org]

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

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org

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

[Bug exp/31005] "Cannot access memory at address 0x0" for inlined function argument

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
I failed in my first attempt at writing a test case for this :(
I guess I will try to debug the original test case.

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

[Bug exp/31005] "Cannot access memory at address 0x0" for inlined function argument

[tromey at sourceware dot org]

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

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
The variable has to have a DW_AT_constant_value to trigger this.

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

[Bug exp/31005] "Cannot access memory at address 0x0" for inlined function argument

[tromey at sourceware dot org]

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

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
I mean s/constant/const

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

[Bug exp/31005] "Cannot access memory at address 0x0" for inlined function argument

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at sourceware dot org   |tromey at sourceware dot org

--- Comment #6 from Tom Tromey <tromey at sourceware dot org> ---
Your patch is reasonably close but I think the LOC_CONST part will
fail for big-endian targets.
I've got a patch and a test case.
I'll see if I can dig up a big-endian machine to test it on.

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

[Bug exp/31005] "Cannot access memory at address 0x0" for inlined function argument

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-11-28

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

[Bug exp/31005] "Cannot access memory at address 0x0" for inlined function argument

[tromey at sourceware dot org]

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

--- Comment #7 from Tom Tromey <tromey at sourceware dot org> ---
https://sourceware.org/pipermail/gdb-patches/2023-November/204599.html

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

[Bug exp/31005] "Cannot access memory at address 0x0" for inlined function argument

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=703adbb1f97db52ed63b2a6a074195b1cee0f132

commit 703adbb1f97db52ed63b2a6a074195b1cee0f132
Author: Tom Tromey <tom@tromey.com>
Date:   Mon Nov 27 16:44:22 2023 -0700

    Fix dynamic type resolution for LOC_CONST and LOC_CONST_BYTES symbols

    PR rust/31005 points out that dynamic type resolution of a LOC_CONST
    or LOC_CONST_BYTES symbol will fail, leading to output like:

        from_index=<error reading variable: Cannot access memory at address
0x0>

    This patch fixes the problem by using the constant value or bytes when
    performing type resolution.

    Thanks to tpzker@thepuzzlemaker.info for a first version of this
    patch.

    I also tested this on a big-endian PPC system (cfarm203).

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

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

[Bug exp/31005] "Cannot access memory at address 0x0" for inlined function argument

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |15.1
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #9 from Tom Tromey <tromey at sourceware dot org> ---
Fixed.

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