Created attachment 15199 [details]
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.