From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id wdQtMHuTBGpjdzYAWB0awg (envelope-from ) for ; Wed, 13 May 2026 11:06:35 -0400 Authentication-Results: simark.ca; dkim=fail reason="signature verification failed" (768-bit key; unprotected) header.d=tromey.com header.i=@tromey.com header.a=rsa-sha256 header.s=default header.b=CklCBX15; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id AD0AC1E0C3; Wed, 13 May 2026 11:06:35 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_INVALID,DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 052621E067 for ; Wed, 13 May 2026 11:06:35 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4EC074BB8F5B for ; Wed, 13 May 2026 15:06:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4EC074BB8F5B Authentication-Results: sourceware.org; dkim=fail reason="signature verification failed" (768-bit key, unprotected) header.d=tromey.com header.i=@tromey.com header.a=rsa-sha256 header.s=default header.b=CklCBX15 Received: from omta38.uswest2.a.cloudfilter.net (omta38.uswest2.a.cloudfilter.net [35.89.44.37]) by sourceware.org (Postfix) with ESMTPS id A8E7F4B92095 for ; Wed, 13 May 2026 15:05:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A8E7F4B92095 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A8E7F4B92095 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=35.89.44.37 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778684757; cv=none; b=L88zub+hYvAxZVQl722T5vvqHeCkJAucrQFCeijEM76gjU72fX0/WxqsD1iaU+qZdcVN60M4pH6lRgk/PL1IOzRfrM6RqNsZSsV/rL+E/IA6WeXa1RQbxEPjoI7wPTMkgBaofpoizjsGNTo88VzNXJ+P8oDtoeVzqClgF0gx4u4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778684757; c=relaxed/simple; bh=WjRTIUVFH9p92DbzWOmcuT5IwitDkHcPqEGGClhGikw=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=cBPnBuK6h7o3MAzMBhku+cgceGmHwT+AOBI7L78+I5Dk/DLm9qtiPAF+w/XVlgIeFhfNXho/LSIzZtn8ZRrbWqoVX77FyZZR2YPXt+DaGhjZ+uIcQndLh+mI4KVyPLbWyq8ADz9t1Fjp7Od6LTHrf8ezo7Z7qZACD0wyYWxRv5Q= ARC-Authentication-Results: i=1; sourceware.org; dkim=policy (768-bit key, unprotected) header.d=tromey.com header.i=@tromey.com header.a=rsa-sha256 header.s=default header.b=CklCBX15 reason="signing key too small" DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A8E7F4B92095 Received: from eig-obgw-5007b.ext.cloudfilter.net ([10.0.29.167]) by cmsmtp with ESMTPS id Mx1AwxBB9jw8YNB9owDBIt; Wed, 13 May 2026 15:05:56 +0000 Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTPS id NB9awHfxgHcweNB9awRsTk; Wed, 13 May 2026 15:05:42 +0000 X-Authority-Analysis: v=2.4 cv=Paj/hjhd c=1 sm=1 tr=0 ts=6a049354 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=NGcC8JguVDcA:10 a=ItBw4LHWJt0A:10 a=20KFwNOVAAAA:8 a=zstS-IiYAAAA:8 a=bybRYLXvd4mvFx3robcA:9 a=4G6NA9xxw8l3yy4pmD5M:22 a=DCx65vhANUyCzuf5D8fC:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=4NPV0h5enAXjpZUinrRfDY58QfKk2hm7NFWCt7IZPPw=; b=CklCBX15Zbxp7VC/lZuFZPntQa w4QyzFCJnevSW01gmJbYWcz/nhj0P1k5B/CgyqVEcukgigZJBMe+1CdNTw+MLd1vY4v6TnSuz/ern ENd50azxJqfHktJ5JNycGtTZl; Received: from 75-166-225-82.hlrn.qwest.net ([75.166.225.82]:48552 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.99.2) (envelope-from ) id 1wNB9Z-00000000xOU-0Mno; Wed, 13 May 2026 09:05:41 -0600 From: Tom Tromey To: Andrew Burgess Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 2/6] gdb: use TARGET_CHAR_BIT more in dwarf2/expr.c In-Reply-To: <7865aefc9044e187b325f71ed2443f1ccf43c30e.1778579473.git.aburgess@redhat.com> (Andrew Burgess's message of "Tue, 12 May 2026 11:07:23 +0100") References: <7865aefc9044e187b325f71ed2443f1ccf43c30e.1778579473.git.aburgess@redhat.com> X-Attribution: Tom Date: Wed, 13 May 2026 09:05:38 -0600 Message-ID: <87tssbl58d.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 75.166.225.82 X-Source-L: No X-Exim-ID: 1wNB9Z-00000000xOU-0Mno X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 75-166-225-82.hlrn.qwest.net (bapiya) [75.166.225.82]:48552 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Org: HG=bhshared;ORG=bluehost; X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-CMAE-Envelope: MS4xfJJntlrNqGmi3bv3PAYYOGoGtpWzFyPlJ31l86jYqOFond1PoA5nevodGxIE2QwhgmcbVCfz5M3zrsARhA6GqC+8NlmgoUcemwqyW8dow7BDgQYIFzFw O+MAo7Aw08K5+YCPC9BTs2U6nH3UtLhaySeqPPyljwD7rOeBsIa2xAaTqhsDRqT8WFF5Iv/WdeEXvn9N1ycO3u783uJAnKpe/rU= X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org >>>>> "Andrew" == Andrew Burgess writes: Andrew> A later commit in this series touches some code in dwarf2/expr.c that Andrew> used "8 * some_byte_count" to convert to a bit count. It seemed Andrew> natural to change this to "TARGET_CHAR_BIT * some_byte_count", but Andrew> when I started looking I realised there's a lot of places in Andrew> dwarf2/expr.c that use "8" instead of "TARGET_CHAR_BIT". Andrew> So I split out this commit to change all of the uses of "8" to Andrew> "TARGET_CHAR_BIT". I believe everywhere I've changed really is doing Andrew> conversions between bits and bytes, so this change is appropriate. FWIW I think there's a lot more code around using '8' (not your problem obviously); but more importantly that TARGET_CHAR_BIT can't really be the correct approach to this problem. For TARGET_CHAR_BIT to work, I think we'd instead have to change all these spots to reference some gdbarch (i.e. in addition to its other problems, "TARGET" is a misnomer). Also, I think some places using TARGET_CHAR_BIT incorrectly mix host and target side data. But, luckily, I also tend to think it's a problem that won't ever need solving. Andrew> if (!check_optimized) Andrew> copy_bitwise (v_contents, offset, Andrew> - buffer.data (), bits_to_skip % 8, Andrew> + buffer.data (), bits_to_skip % TARGET_CHAR_BIT, Andrew> this_size_bits, bits_big_endian); In this situation it seems to me that gdb is manipulating host-side data. So here, using '8' (really HOST_CHAR_BIT) seems more appropriate, since otherwise the wrong number of bits will be manipulated. I didn't go through all the spots to find which are which. And TBH unless someone is really porting to such an architecture, it seems a little pointless, in the sense that there isn't a good way to test this anyway -- and even if we came up with one through some heroics, would we really want to bother? Andrew> - bit_offset += 8 * value->offset (); Andrew> + bit_offset += TARGET_CHAR_BIT * value->offset (); Other spots like this do make sense, because the bit offset is a function of the size of a target byte. Anyway, despite all this I have no objection to this patch and I even approve it, with my reasons being that (1) TARGET_CHAR_BIT at least indicates places that maybe need to be examined should anyone ever do this work (though searching for "8" does the same); (2) anyway there are probably already many incorrect uses in the tree; and (3) using a name is better than "8". Approved-By: Tom Tromey Tom