public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "tpzker at thepuzzlemaker dot info" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug exp/31005] New: "Cannot access memory at address 0x0" for inlined function argument Date: Sat, 28 Oct 2023 19:34:52 +0000 [thread overview] Message-ID: <bug-31005-4717@http.sourceware.org/bugzilla/> (raw) 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.
next reply other threads:[~2023-10-28 19:34 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-10-28 19:34 tpzker at thepuzzlemaker dot info [this message] 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
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-31005-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).