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 #7 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Pedro Alves from comment #6)
> I'm having mixed feelings about LONGEST->__int128  :-(  A lot of code uses
> (U)LONGEST for indexes, sizes and also to hold register values.  Most of
> these places won't ever need the extended precision.  I'm not sure whether
> forcing everything to use 128-bit is a good idea, both efficiency/ABI -wise,
> and memory-space wise.  :-/

Yes, I agree.  I took this approach because I thought there was a chance
that I could get 128-bit support working this way; because my feeling is
that the other ways are probably difficult.

What would be a better plan?

Printing seems reasonably contained, perhaps.  We could introduce
analogues of the print-utils functions that work on gdb_byte arrays,
supporting larger widths (avoiding the need for __int128 on the host).
I suppose there aren't many spots that would need to be changed to make
this work.

Arithmetic seems difficult.  Maybe a new type for this, then (the hard part)
change various places to use the new type rather than (U)LONGEST?
It seems like it would hard to even find the places, unless maybe the new
type was a class that did not allow conversions from integer types.
Hmm...

I wonder if the Python layer also needs updates to be able to represent
such values in Python.

This sounds like a project probably out of reach of my free time.

-- 
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]