This is the mail archive of the gdb-patches@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]

Re: [RFC 12/23] regcache: Add functions suitable for regset_supply/collect.


On Mon, May 05 2014, Mark Kettenis wrote:

>> From: Andreas Arnez <arnez@linux.vnet.ibm.com>
>> Date: Mon, 28 Apr 2014 11:54:12 +0200
>> 
>> These functions are intended to suit all targets that don't require too
>> special logic in their regset supply/collect methods.  Having such
>> generic functions helps reducing target-specific complexity.
>> 
>> gdb/
>> 	* regcache.c: Include "regset.h".
>> 	(regcache_supply_regset, regcache_collect_regset): New functions.
>> 	* regcache.h (struct regcache_map_entry): New structure.
>> 	(REGCACHE_MAP_SKIP_BYTES): New enum value.
>> 	(regcache_supply_regset, regcache_collect_regset): New prototypes.
>
> Sorry, but this doesn't strike me as a particular good interface.
> I'd say an approach that uses explicit offsets would be much better.

And this is because...?

Existing maps greatly differ.  There are lists of offset/regnum tuples,
or arrays of regnums where the indexes implicitly represent offsets, or
the other way around, or something completely special.  In addition to
maps, many targets have special logic in their supply/collect functions,
and in some cases there are not even any maps, but only code.  Thus,
finding a map format that suits most of the existing targets seems like
a fairly difficult task to me.  Nevertheless, I tried, and I considered
all of the above approaches (including "explicit-offset" map formats),
and more.

Here are some reasons why I ended up with this format:

* The "look and feel" is similar to a structure definition with array
  members.  This seems straightforward and makes a map easily comparable
  to a "struct pt_regs" or such.

* The same map is usable for different word sizes.

* Maps are usually shorter than with other existing map formats.

* With this format, there are cases where I could reduce or completely
  eliminate the special logic in the supply/collect functions.

If it helps to widen the use of the map format, I'd be happy to adjust
it, but I'm hesitant to give up these benefits.


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