From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24461 invoked by alias); 5 May 2014 15:34:27 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 24450 invoked by uid 89); 5 May 2014 15:34:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e06smtp18.uk.ibm.com Received: from e06smtp18.uk.ibm.com (HELO e06smtp18.uk.ibm.com) (195.75.94.114) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 05 May 2014 15:34:25 +0000 Received: from /spool/local by e06smtp18.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 5 May 2014 16:34:22 +0100 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp18.uk.ibm.com (192.168.101.148) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 5 May 2014 16:34:20 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id D2B93219004D for ; Mon, 5 May 2014 16:34:11 +0100 (BST) Received: from d06av05.portsmouth.uk.ibm.com (d06av05.portsmouth.uk.ibm.com [9.149.37.229]) by b06cxnps4075.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s45FYKmW64618692 for ; Mon, 5 May 2014 15:34:20 GMT Received: from d06av05.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av05.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s45FYJ55019741 for ; Mon, 5 May 2014 09:34:19 -0600 Received: from br87z6lw.de.ibm.com (sig-9-145-104-183.uk.ibm.com [9.145.104.183]) by d06av05.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s45FYIQ7019705; Mon, 5 May 2014 09:34:19 -0600 From: Andreas Arnez To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: [RFC 12/23] regcache: Add functions suitable for regset_supply/collect. References: <87eh0h6bkq.fsf@br87z6lw.de.ibm.com> <87vbtt3hkr.fsf@br87z6lw.de.ibm.com> <201405051002.s45A2JOU026418@glazunov.sibelius.xs4all.nl> Date: Mon, 05 May 2014 15:34:00 -0000 In-Reply-To: <201405051002.s45A2JOU026418@glazunov.sibelius.xs4all.nl> (Mark Kettenis's message of "Mon, 5 May 2014 12:02:19 +0200 (CEST)") Message-ID: <87wqe0jl39.fsf@br87z6lw.de.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14050515-6892-0000-0000-000008AD2C81 X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00043.txt.bz2 On Mon, May 05 2014, Mark Kettenis wrote: >> From: Andreas Arnez >> 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.