This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug rust/21185] add i128 and u128 support to rust
- From: "tromey at sourceware dot org" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Fri, 19 May 2017 15:34:34 +0000
- Subject: [Bug rust/21185] add i128 and u128 support to rust
- Auto-submitted: auto-generated
- References: <bug-21185-4717@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=21185
--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Pedro Alves from comment #4)
> I expect you'll run into lots of assumptions that LONGEST == 64-bit.
Yeah. There were some spots in a few tdeps that assume that CORE_ADDR
and ULONGEST are the same type. aarch64-tdep helpfully had self-tests
pointing out some invalid assumptions -- not so with the other ones.
And print-utils makes 64 bit assumptions.
> Do many places in the codebase need to learn about the types? What does the
> hack spare you from doing manually? Arithmetic?
I don't have a complete overview of the situation, but some things:
* Printing a 128-bit integer doesn't work well right now.
... but that's print-utils, which currently use LONGEST/ULONGEST.
Could be done manually for Rust, but since GCC has __int128 that
doesn't seem best.
* Arithmetic. This maybe means reimplementing a bunch of the value API?
E.g. value_as_long returns a LONGEST.
Could operate on the bytes instead, GMP-style.
Hmm, maybe that's all I've got so far.
I pushed the int-128 branch to my github in case you want to take a peek.
--
You are receiving this mail because:
You are on the CC list for the bug.