public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug exp/31005] New: "Cannot access memory at address 0x0" for inlined function argument
@ 2023-10-28 19:34 tpzker at thepuzzlemaker dot info
  2023-10-28 19:35 ` [Bug exp/31005] " tpzker at thepuzzlemaker dot info
                   ` (11 more replies)
  0 siblings, 12 replies; 13+ messages in thread
From: tpzker at thepuzzlemaker dot info @ 2023-10-28 19:34 UTC (permalink / raw)
  To: gdb-prs

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.

^ permalink raw reply	[flat|nested] 13+ messages in thread
end of thread, other threads:[~2023-12-08 15:16 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-28 19:34 [Bug exp/31005] New: "Cannot access memory at address 0x0" for inlined function argument tpzker at thepuzzlemaker dot info
2023-10-28 19:35 ` [Bug exp/31005] " tpzker at thepuzzlemaker dot info
2023-10-28 19:36 ` tpzker at thepuzzlemaker dot info
2023-10-28 21:05 ` tpzker at thepuzzlemaker dot info
2023-10-29 10:06 ` sam at gentoo dot org
2023-11-26 19:50 ` tromey at sourceware dot org
2023-11-28  0:15 ` tromey at sourceware dot org
2023-11-28  0:16 ` tromey at sourceware dot org
2023-11-28  0:58 ` tromey at sourceware dot org
2023-11-28  0:59 ` tromey at sourceware dot org
2023-11-28 21:54 ` tromey at sourceware dot org
2023-12-08 15:16 ` cvs-commit at gcc dot gnu.org
2023-12-08 15:16 ` tromey at sourceware dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).