From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17240 invoked by alias); 3 Mar 2020 21:31:15 -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 17232 invoked by uid 89); 3 Mar 2020 21:31:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Mar 2020 21:31:13 +0000 Received: from [172.16.0.95] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 42E441E5F3; Tue, 3 Mar 2020 16:31:12 -0500 (EST) Subject: Re: [PATCH] Implement debugging of WOW64 processes To: Hannes Domani , Gdb-patches References: <20200303182057.8973-1-ssbssa.ref@yahoo.de> <20200303182057.8973-1-ssbssa@yahoo.de> <834kv5xoef.fsf@gnu.org> <1055408447.6034972.1583262721877@mail.yahoo.com> <83y2shw81q.fsf@gnu.org> <4b854f69-10ea-eada-f4ba-245a02aae2e6@simark.ca> <83wo81w5cu.fsf@gnu.org> <140963475.6133151.1583269956021@mail.yahoo.com> From: Simon Marchi Message-ID: <5c9e53bd-cbd1-cd59-e701-43a1e76aee3b@simark.ca> Date: Tue, 03 Mar 2020 21:31:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <140963475.6133151.1583269956021@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-03/txt/msg00073.txt On 2020-03-03 4:12 p.m., Hannes Domani via gdb-patches wrote: > I'm not very fond of the code duplication either. > The only way I can think of, is to refactor it into template functions that > can accept both CONTEXT or WOW64_CONTEXT. > Is this what you had in mind also, or do you have a better idea? I didn't really have something specific in mind. However, I'm thinking that sprinkling the code with if/else such as: /* Do something */ #ifdef __x86_64__ if (wow64_process) { ... } #endif else { ... } ... does not help with readability and maintenance. To address that, we could have an interface with two concrete implementations (one for "standard" processes and one for WOW64 processes). We would choose and instantiate the right implementation at runtime (at the place where you currently set the wow64_process variable), so the code above would become: /* Do something */ impl->do_something (); where the actual code is in each of the implementations' do_something methods. That itself wouldn't reduce the code duplication. But it would keep the specificities of dealing with a standard process vs a WOW64 process at a single place. To reduce code duplication, if there is any chance of sharing code between the two implementations, it could be done by having helper methods in the base class and / or using templates, as you said. Simon