public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug rust/31082] New: rust-parse infers `0xffffffd00000009a` and other addresses as i128, preventing `as *mut _` coercions in `print`
@ 2023-11-23 17:26 tpzker at thepuzzlemaker dot info
  2023-11-23 17:37 ` [Bug rust/31082] " tpzker at thepuzzlemaker dot info
                   ` (5 more replies)
  0 siblings, 6 replies; 7+ messages in thread
From: tpzker at thepuzzlemaker dot info @ 2023-11-23 17:26 UTC (permalink / raw)
  To: gdb-prs

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

            Bug ID: 31082
           Summary: rust-parse infers `0xffffffd00000009a` and other
                    addresses as i128, preventing `as *mut _` coercions in
                    `print`
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: rust
          Assignee: unassigned at sourceware dot org
          Reporter: tpzker at thepuzzlemaker dot info
  Target Milestone: ---

Created attachment 15226
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15226&action=edit
[PATCH] rust-parse: Infer some integer constants as u64

I've been working on an operating system in Rust for learning purposes, and
have found myself having to deal with addresses greater than `2^63-1` due to
canonicalization and higher-half kernels. Due to a bug (#29735) in GDB 13.2,
fixed in GDB 14 HEAD, however, I have been using the GDB 14 branch to perform
debugging.

However, when trying to print expressions as such:
```
p (0xffffffd00000009a as *mut u64)
```
The system returns an error: `That operation is not available on integers of
more than 8 bytes.`

To reproduce this, compile a simple Rust program like such (in `tmp.rs`, for
example):
```rs
fn main() { println!("hello world!") }
```
Then `b tmp::main` and run the print command above.

After some debugging, I've discovered that this stems from the following patch:
https://sourceware.org/pipermail/gdb-patches/2023-March/198410.html

This patch added support for `i128`, however in this process, made all `u64`s
`(2 ** 63) - 1 <= x <= (2 ** 64) - 1` inferred to be i128s, when they really
should be `u64`s. This causes the `as *mut u64` operation to fail.

This only occurs for addresses in the higher half, and not any other
addresses--perhaps why it was not discovered earlier.

I have attached a patch that is a bit hacky, but does solve this issue. It will
regress some inference of large values as i128, however, and that will require
explicit suffixing as `[number]i128`. I'm not sure how to better solve that,
though.

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

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

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-23 17:26 [Bug rust/31082] New: rust-parse infers `0xffffffd00000009a` and other addresses as i128, preventing `as *mut _` coercions in `print` tpzker at thepuzzlemaker dot info
2023-11-23 17:37 ` [Bug rust/31082] " tpzker at thepuzzlemaker dot info
2023-11-24 16:37 ` tromey at sourceware dot org
2023-11-24 16:56 ` tromey at sourceware dot org
2023-11-25  2:26 ` tromey at sourceware dot org
2023-12-08 15:39 ` cvs-commit at gcc dot gnu.org
2023-12-08 15:39 ` 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).