I tried a hack that typedefs LONGEST and ULONGEST using __int128.
This found a couple of type errors in the source.
Unfortunately the resulting gdb doesn't seem to work properly.

I fixed up a few things and I'm sending this through the buildbot.
I wonder though if this makes sense to put in.
And, I wonder if my simple changes are really sufficient, given
what I've already had to patch.

And, hah, the results are really bad.

I expect you'll run into lots of assumptions that LONGEST == 64-bit.

Do many places in the codebase need to learn about the types?  What does the hack spare you from doing manually?  Arithmetic?

(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.

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.  :-/

(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.

Maybe printing doesn't need much attention, since now I see
the print_*_chars family of functions in valprint.c.
Weird that I've never run into these before.

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

Yeah, I think a class (plus arithmetic operators) would be what I'd try too.  
Maybe we could borrow gcc's wide_int (or parts of it).

Not sure about disabling conversions from integer types.  I'd assume it to be handy, to allow natural initialization from 0 and 1 [integer foo = 1;], etc.  I'd think that it's conversion to (narrower) integer types that would be an issue.

(In reply to Pedro Alves from comment #9)
> > 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...
> 
> Yeah, I think a class (plus arithmetic operators) would be what I'd try too.
> 
> Maybe we could borrow gcc's wide_int (or parts of it).
> 
> Not sure about disabling conversions from integer types.  I'd assume it to
> be handy, to allow natural initialization from 0 and 1 [integer foo = 1;],
> etc.  I'd think that it's conversion to (narrower) integer types that would
> be an issue.

Yeah, duh, that makes sense.

I've got some cleanups to the scalar printing code that might be useful.
Not quite done -- there's some weird stuff in there.
I haven't looked at the arithmetic stuff.

This is pretty close, I think, but it turns out there are some tests
that rely on the current behavior where gdb will print 128 bit values
with zero padding; whereas the patch series I have turns this off.
Updating the tests isn't too bad, so far, but since some occur in
arch-specific tests I suspect there will be some that I can't test.

Printing got fixed in bug 16225, but I think I want to leave this one
open to implement arithmetic.

I'm going to close this in favor of the other bug.

*** This bug has been marked as a duplicate of bug 20991 ***

Un-duping and repurposing again as the rust lexer / parser
part of 128-bit ints.

Working on a patch.

https://sourceware.org/pipermail/gdb-patches/2023-March/198407.html

The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d760ae22b964995234e14e090ba179311382b90d

commit d760ae22b964995234e14e090ba179311382b90d
Author: Tom Tromey <tromey@adacore.com>
Date:   Mon Mar 27 13:05:03 2023 -0600

    Add 128-bit integer support to the Rust parser
    
    This adds support for 128-bit integers to the Rust parser.
    
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21185

Really fixed.