From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sa-prd-fep-048.btinternet.com (mailomta26-sa.btinternet.com [213.120.69.32]) by sourceware.org (Postfix) with ESMTPS id D9C353857C43 for ; Fri, 18 Sep 2020 16:31:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D9C353857C43 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=jon.turney@dronecode.org.uk Received: from sa-prd-rgout-002.btmx-prd.synchronoss.net ([10.2.38.5]) by sa-prd-fep-048.btinternet.com with ESMTP id <20200918163155.EAQZ4139.sa-prd-fep-048.btinternet.com@sa-prd-rgout-002.btmx-prd.synchronoss.net> for ; Fri, 18 Sep 2020 17:31:55 +0100 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com X-Originating-IP: [86.176.137.240] X-OWM-Source-IP: 86.176.137.240 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedujedrtdeigddutdefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhepuffvfhfhkffffgggjggtgfesthejredttdefjeenucfhrhhomheplfhonhcuvfhurhhnvgihuceojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukheqnecuggftrfgrthhtvghrnhepgeeuhfekvdefieeghfehtdejheeigedthefhhfehfffgheehgedtffeljeetueeunecukfhppeekiedrudejiedrudefjedrvdegtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddrudduudgnpdhinhgvthepkeeirddujeeirddufeejrddvgedtpdhmrghilhhfrhhomhepoehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkqecuuefqffgjpeekuefkvffokffogfdprhgtphhtthhopeeoghgusgdqphgrthgthhgvshesshhouhhrtggvfigrrhgvrdhorhhgqe X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.111] (86.176.137.240) by sa-prd-rgout-002.btmx-prd.synchronoss.net (5.8.340) (authenticated as jonturney@btinternet.com) id 5ED9AA6E119522F0 for gdb-patches@sourceware.org; Fri, 18 Sep 2020 17:31:55 +0100 Subject: Re: [PATCH 2/4] Add amd64_windows_gregset_reg_offset To: gdb-patches@sourceware.org References: <20200812191816.23246-1-jon.turney@dronecode.org.uk> <20200812191816.23246-3-jon.turney@dronecode.org.uk> From: Jon Turney Message-ID: <73d73956-a03d-1f75-bdfc-c3dc785194f7@dronecode.org.uk> Date: Fri, 18 Sep 2020 17:31:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2020 16:31:58 -0000 On 20/08/2020 23:08, Simon Marchi wrote: > On 2020-08-12 3:18 p.m., Jon Turney wrote: >> Register a gregset_reg_offset array for Cygwin x86_64 core dump parsing >> (this causes the generic i386_iterate_over_regset_sections() '.reg' >> section iterator to get installed by i386_gdbarch_init()). One thing I notice is that, after this change, we now have (for both x86 and x86_64), a mapping between regno and CONTEXT offset both as a gregset_reg_offset mapping (used when interpreting coredumps) and a similar mapping fed into windows_set_context_register_offsets() (used on an inferior process). There's probably some scope for de-duplication and genericization there. >> gdb/ChangeLog: >> >> 2020-07-01 Jon Turney >> >> * amd64-windows-tdep.c(amd64_windows_gregset_reg_offset): Add. >> (amd64_windows_init_abi_common): ... and register. > > That looks reasonable. I think i386_iterate_over_regset_sections should > be made static, if you want to make another (obvious I would say) patch.