RE: [PATCH 00/26] gdbserver: refactor regcache and allow gradually populating

["Aktemur, Tankut Baris" <tankut.baris.aktemur@intel.com>]

On Tuesday, March 7, 2023 9:40 PM, Tom Tromey wrote:
> >>>>> Tankut Baris Aktemur via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
> > Gdbserver's regcache is defined and used in a way that it is either
> > invalid or fetches all the registers from the target prior to being
> > used.  It also seems some regcache functions have two different contracts
> > based on argument values (e.g. a buffer being nullptr).
> 
> > This is an attempt to refactor the regcache in gdbserver to
> 
> >   - convert several free functions to methods.
> >   - use and update register statuses more consistently.
> >   - allow populating register values gradually, instead of having to
> >     fetch all register values from the target.
> 
> I haven't read these patches, but I wanted to mention that, over time,
> we've been trying to bring gdb and gdbserver closer together where
> possible.  And, I'm wondering how this series fits into this.  At the
> end, are the two register caches more similar?  More divergent?
> 
> I'm not necessarily saying this is the most important thing, but for
> example what would be unfortunate is if the two ended up with similar
> functionality but very different expressions, which would make the
> sharing of other code even harder.
> 
> Tom

Hello Tom,

The regcache implementation in gdb is a lot more involved with its relation
to gdbarch, pseudo registers, values, etc. that do not exist at the gdbserver
side.  As far as I can tell, gdbserver's regcache can/should be compared with
gdb's reg_buffer.  The series I posted does not strictly aim at sharing code.
But from a general perspective, I think it would be fair to say that the
refactorings I posted bring gdbserver's regcache's behavior closer to the definitions
in gdb.  E.g. the use of REG_VALID/UNKNOWN/UNAVAILABLE statuses and the moving
of free functions to class methods.  For true code sharing, however, there is
much work to do, in my opinion.

The series at the end introduces a REG_DIRTY status as a new state. This does
not exist in the gdb side and could be considered a divergence.

Regards
-Baris

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928