From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id MDF7HtZYMmEBFQAAWB0awg (envelope-from ) for ; Fri, 03 Sep 2021 13:18:14 -0400 Received: by simark.ca (Postfix, from userid 112) id 7A2901EE22; Fri, 3 Sep 2021 13:18:14 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id D8BF31EDF5 for ; Fri, 3 Sep 2021 13:18:13 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 657563847801 for ; Fri, 3 Sep 2021 17:18:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 657563847801 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1630689493; bh=hycsYxVO8OK6vIst8Tr0msA1BMzpNyQDZwdkko9AaIU=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=FI0qMt8LDAhjssAOpW1/sNb8fS8bFOEocV4T5OUiFPPxpSHqzwhqYCDQBUX1O5eMZ ZEjVsd7DuuUlYLnDmeVuG04U7bBj+YspnUIrxq+uvSkalNtOnf+jqyHEokQOh0fHdY MKwzqhv+VWvYjtsNATnZVbNc2EzmQ8VyLIw63TUc= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 558C4384B13A for ; Fri, 3 Sep 2021 17:17:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 558C4384B13A Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 183HHmZE001522 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 3 Sep 2021 13:17:53 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 183HHmZE001522 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (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 963FE1EDF5; Fri, 3 Sep 2021 13:17:48 -0400 (EDT) Subject: Re: [PATCH] Use CORE_ADDR as return type from x86_dr_low_get_addr To: Tom Tromey References: <20210903163219.2590419-1-tromey@adacore.com> <87mtotli5k.fsf@tromey.com> <875yvhlhkv.fsf@tromey.com> Message-ID: <6ca2366b-f033-4dcd-c1e1-13a86c6d2205@polymtl.ca> Date: Fri, 3 Sep 2021 13:17:48 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <875yvhlhkv.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 3 Sep 2021 17:17:48 +0000 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: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 2021-09-03 1:00 p.m., Tom Tromey wrote: > Tom> It just seemed to me that, most of the time, the value really is a > Tom> CORE_ADDR, and that anyway a CORE_ADDR would definitely be large enough. > > Thinking about this a bit more -- it seems wrong to me to use uintptr_t > (a host type) to represent a register value (a target type). So from > this perspective, CORE_ADDR is more correct. Now, it's not completely > correct in the sense that not every DR register holds an address. But, > it's at least harmless in those cases. This is in windows-nat.c, where host == target, so I think uintptr_t is somewhat correct given the uses cases we want to support (GDB 32 debugging inferior 32, GDB 64 debugging inferior 32 and GDB 64 debugging inferior 64). If it were in windows-tdep.c, it would definitely be wrong. But uintptr_t isn't any more correct than CORE_ADDR, so I'm not against the change either. Simon