This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug rust/21185] add i128 and u128 support to rust


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]