This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2 02/13] regcache: Add functions suitable for regset_supply/collect.
- From: Omair Javaid <omair dot javaid at linaro dot org>
- To: Andreas Arnez <arnez at linux dot vnet dot ibm dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, Yao Qi <yao at codesourcery dot com>, Mark Kettenis <kettenis at gnu dot org>
- Date: Wed, 9 Jul 2014 00:08:53 +0500
- Subject: Re: [PATCH v2 02/13] regcache: Add functions suitable for regset_supply/collect.
- Authentication-results: sourceware.org; auth=none
- References: <1403714949-28133-1-git-send-email-arnez at linux dot vnet dot ibm dot com> <1403714949-28133-3-git-send-email-arnez at linux dot vnet dot ibm dot com> <CANW4E-0cEaQ=DLN5SVjWtCiHCK5iDDqUFnEgKbACig+pe4pW_A at mail dot gmail dot com> <87lhs4f5ng dot fsf at br87z6lw dot de dot ibm dot com>
On 8 July 2014 16:31, Andreas Arnez <arnez@linux.vnet.ibm.com> wrote:
> On Mon, Jul 07 2014, Omair Javaid wrote:
>
>> Is there a way around avoiding the loop in supply/collect where regnum
>> != -1? It should be more efficient in cases where we are looking for a
>> register with regnum > 0.
>
> Good question. The most straightforward way would be a register map
> format where regnum is used as an index into an array of offsets, like
> this:
>
> int s390_regmap_gregset[S390_NUM_REGS] =
> {
> /* Program Status Word. */
> 0x00, 0x04,
> /* General Purpose Registers. */
> 0x08, 0x0c, 0x10, 0x14,
> 0x18, 0x1c, 0x20, 0x24,
> 0x28, 0x2c, 0x30, 0x34,
> 0x38, 0x3c, 0x40, 0x44,
> /* Access Registers. */
> 0x48, 0x4c, 0x50, 0x54,
> 0x58, 0x5c, 0x60, 0x64,
> 0x68, 0x6c, 0x70, 0x74,
> 0x78, 0x7c, 0x80, 0x84,
> /* Floating Point Control Word. */
> -1,
> /* Floating Point Registers. */
> -1, -1, -1, -1, -1, -1, -1, -1,
> -1, -1, -1, -1, -1, -1, -1, -1,
> /* GPR Uppper Halves. */
> -1, -1, -1, -1, -1, -1, -1, -1,
> -1, -1, -1, -1, -1, -1, -1, -1,
> /* GNU/Linux-specific optional "registers". */
> 0x88, -1, -1,
> };
>
> This is a real example. For the full example refer to:
>
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/s390-tdep.c;h=72d55450225e89da4394079efac1fa33b36cb68c;hb=d91fab15e7eb04f6c9b7fee5859d8815b7aa84ee#l412
>
> As you see, this is where the s390 implementation came from. Then I
> realized that regnum > 0 is a very rare case, and that the common case
> was suboptimal with this format, because the supply/collect functions
> had to iterate over *all* registers, not just those of a specific
> regset.
>
> Patch #3 in this series expresses the regmap from above like this:
>
> static const struct regcache_map_entry s390_gregmap[] =
> {
> { 1, S390_PSWM_REGNUM },
> { 1, S390_PSWA_REGNUM },
> { 16, S390_R0_REGNUM },
> { 16, S390_A0_REGNUM },
> { 1, S390_ORIG_R2_REGNUM },
> { 0 }
> };
>
> In addition to being more efficient in the common case, I also consider
> this version much easier to read and maintain.
>
> We could certainly spend more effort on supplying and collecting a
> single register more efficiently. For instance, we could offer
> additional routines for that special case, perhaps in conjunction with a
> preparation function that converts a regmap to an indexed-by-regnum
> array. However, I wouldn't focus on that too much before actually
> making use of it. Note that currently these functions are *always*
> called with regnum == -1.
>
> In fact, it may be more adequate to completely get rid of the parameter
> regnum in the regset supply/collect functions. Any reason why we
> shouldn't?
I think you are right its better off if we leave the single register
variants to target specific *-tdep where they can be retrieved using
regcache_raw_ supply/collect functions. All other options to get
around the loops wont be trivial.