From: Andreas Arnez <arnez@linux.vnet.ibm.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC 12/23] regcache: Add functions suitable for regset_supply/collect.
Date: Mon, 05 May 2014 15:34:00 -0000 [thread overview]
Message-ID: <87wqe0jl39.fsf@br87z6lw.de.ibm.com> (raw)
In-Reply-To: <201405051002.s45A2JOU026418@glazunov.sibelius.xs4all.nl> (Mark Kettenis's message of "Mon, 5 May 2014 12:02:19 +0200 (CEST)")
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.
next prev parent reply other threads:[~2014-05-05 15:34 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-28 9:35 [RFC 00/23] Regset rework preparations Andreas Arnez
2014-04-28 9:39 ` [RFC 01/23] Constify regset structures Andreas Arnez
2014-05-05 9:45 ` Mark Kettenis
2014-04-28 9:40 ` [RFC 02/23] Remove 'arch' field from regset structure Andreas Arnez
2014-05-05 9:32 ` Mark Kettenis
2014-05-05 13:35 ` Andreas Arnez
2014-04-28 9:44 ` [RFC 03/23] AARCH64: Replace regset_alloc() invocations by static regset structures Andreas Arnez
2014-04-28 9:46 ` [RFC 04/23] ARM: " Andreas Arnez
2014-04-28 9:47 ` [RFC 05/23] X86: " Andreas Arnez
2014-04-28 15:33 ` Mark Kettenis
2014-04-29 8:58 ` Andreas Arnez
2014-04-28 9:48 ` [RFC 06/23] MIPS: " Andreas Arnez
2014-04-28 9:49 ` [RFC 07/23] MN10300: " Andreas Arnez
2014-04-28 9:50 ` [RFC 08/23] SCORE: Replace regset_alloc() invocation by a static regset structure Andreas Arnez
2014-04-28 9:51 ` [RFC 09/23] SPARC: Rename register maps from "*regset" to "*regmap" Andreas Arnez
2014-05-05 9:50 ` Mark Kettenis
2014-04-28 9:52 ` [RFC 10/23] SPARC: Replace regset_alloc() invocations by static regset structures Andreas Arnez
2014-05-05 9:52 ` Mark Kettenis
2014-04-28 9:53 ` [RFC 11/23] Drop regset_alloc() Andreas Arnez
2014-05-05 9:53 ` Mark Kettenis
2014-04-28 9:54 ` [RFC 12/23] regcache: Add functions suitable for regset_supply/collect Andreas Arnez
2014-05-05 10:02 ` Mark Kettenis
2014-05-05 15:34 ` Andreas Arnez [this message]
2014-04-28 9:54 ` [RFC 13/23] S390: Migrate to regcache_supply/collect_regset Andreas Arnez
2014-04-28 9:55 ` [RFC 14/23] AARCH64 Linux: Fill 'collect_regset' in regset structures Andreas Arnez
2014-04-28 9:56 ` [RFC 15/23] ALPHA " Andreas Arnez
2014-04-28 9:57 ` [RFC 16/23] FRV " Andreas Arnez
2014-04-28 9:58 ` [RFC 17/23] HPPA " Andreas Arnez
2014-04-28 9:59 ` [RFC 19/23] NIOS2 Linux: Fill 'collect_regset' in regset structure Andreas Arnez
2014-04-28 9:59 ` [RFC 18/23] M32R " Andreas Arnez
2014-04-28 10:00 ` [RFC 20/23] SCORE: " Andreas Arnez
2014-04-28 10:01 ` [RFC 21/23] TILEGX Linux: " Andreas Arnez
2014-04-28 10:01 ` [RFC 22/23] M68K Linux: Define regset structures Andreas Arnez
2014-04-28 10:02 ` [RFC 23/23] IA64 " Andreas Arnez
2014-04-28 15:29 ` [RFC 00/23] Regset rework preparations Maciej W. Rozycki
2014-04-28 15:38 ` Andreas Arnez
2014-05-08 10:31 ` Andreas Arnez
2014-05-05 8:09 ` [ping] " Andreas Arnez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wqe0jl39.fsf@br87z6lw.de.ibm.com \
--to=arnez@linux.vnet.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=mark.kettenis@xs4all.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox