From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117640 invoked by alias); 10 Jul 2019 16:05:05 -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 117632 invoked by uid 89); 10 Jul 2019 16:05:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1152, HContent-Transfer-Encoding:8bit 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; Wed, 10 Jul 2019 16:05:04 +0000 Received: from [172.16.0.120] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 510A31E472; Wed, 10 Jul 2019 12:05:02 -0400 (EDT) Subject: Re: [PATCH 3/7] Arm: Add read_description read funcs and use in GDB To: Alan Hayward Cc: "gdb-patches@sourceware.org" , nd References: <20190705094525.51536-1-alan.hayward@arm.com> <20190705094525.51536-4-alan.hayward@arm.com> <2a5d9c40-e3d9-8827-9301-df4ae4212183@simark.ca> <6071A4B3-3D8F-4C63-88FA-0DA2AB506F1C@arm.com> From: Simon Marchi Message-ID: Date: Wed, 10 Jul 2019 16:05:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2019-07/txt/msg00261.txt.bz2 On 2019-07-10 10:26 a.m., Alan Hayward wrote: >>> If it doesn't make sense to have this function shared with GDBserver (given >>> that GDBserver doesn't run on Cortex-Ms), it should probably go in gdb/arm-tdep.c. >> >> Right. I wasn’t thinking of arch as “architecture code shared with gdbserver”, >> but it makes sense. >> >> The GDBSERVER defines do vanish later in the series. >> >> I think I preferred having the two functions together in arch, but I’ve moved it. >> > > To this, I’ll add that moving the mprofile function into arm-tdep.c means that > in a later patch, both arm-tdep.c and arch/arm.c have to > #include "features/arm/arm-vfpv2.c” > > This is because ARM_M_TYPE_VFP_D16 uses the vfpv2 functions. > > It works, but means that the same static function is being included twice. > > > Alan. Ok, well I agree that the end result looks ok, it's not a big deal if there is a function in arch/arm.h that only gdb uses. It's true that it also makes sense to keep these functions together. I was just a bit put off by the "#ifndef GDBSERVER" initially. Simon