From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 34D933858D1E for ; Mon, 6 May 2024 00:54:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 34D933858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 34D933858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714956888; cv=none; b=hopulZ00CkrdDOn3n9T8B1u7dJo6Tkc+58iEnADq6+kTWIa36uzmA0Am0K4bkksr377CKGOPJjRHsJnacM9xK5o8p0MmvsAm6e8eMLn3NuceSXCQsgTYqTD/qHyTv9SyuQ2/bRKwqI2/SPXwqSRoJJyOZ/bxnzAtp7Trgi4Wh3M= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714956888; c=relaxed/simple; bh=6ssp6lCFO1gQKpEVEZpFIGVFxbMKvQmisQb8RXWbphU=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=LKvQYIW9lqmTw31wmoa6jH8zTeJ+DWmGl+5l9lPd07yKl5FZwyRnQyp8vUu0yq3PONvhZCASrE1J9dXL3GXrUcMtMvISyjcsutDI4BqYAvRD7uxvk+y1IUzkHVV3go9YHtCEVjMNKCW7BRvYG7mpCFqkMfkIDNfFhO5ML4jI9kY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1714956886; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nhdgq+eowufWs/3y8cAWGCsDB5K88lb8nXyyumNCQVE=; b=Tsvs6J3gm6i+5GCkJNTt+COZNtGSlYmy17tEl3YHaJMdbrSO0Tz4W1NkxqGfFIi9Z6ZLtX iaMG6V59DPu/rtfwD4ug+p5pedIjZ3QDk/FqBZF/XexZS2ujFM7ZsZ5HOhcYksfItaY2TW NSQqt/b279WDulLOpmoWEFeZfhSALuk= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-216-h2WzH0OJPDywLWMQS9_wmg-1; Sun, 05 May 2024 20:54:41 -0400 X-MC-Unique: h2WzH0OJPDywLWMQS9_wmg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (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 mimecast-mx02.redhat.com (Postfix) with ESMTPS id 5FCE18943A1; Mon, 6 May 2024 00:54:41 +0000 (UTC) Received: from f40-zbm-amd (unknown [10.22.16.14]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7B25340C6CC1; Mon, 6 May 2024 00:54:40 +0000 (UTC) Date: Sun, 5 May 2024 17:54:39 -0700 From: Kevin Buettner To: Pedro Alves Cc: gdb-patches@sourceware.org, Tom Tromey , Tom de Vries Subject: Re: [PATCH] [gdb/exp] Fix cast handling for indirection Message-ID: <20240505175439.4a1c3317@f40-zbm-amd> In-Reply-To: <1b81045d-5353-49cf-b80e-f64498dd3562@palves.net> References: <20240502154902.22575-1-tdevries@suse.de> <20240502193145.5da7327d@f39-zbm-amd> <8734qyex0l.fsf@tromey.com> <51de396e-67fc-4451-a13e-091178d188f7@palves.net> <20240503103050.2ef46699@f39-zbm-amd> <1b81045d-5353-49cf-b80e-f64498dd3562@palves.net> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Sat, 4 May 2024 00:26:49 +0100 Pedro Alves wrote: > I kind of emphasized the sign extension part above, but to be clear, with > > (gdb) p (long long)*a_loc() > > and gdb assuming that means a_loc returns "long long *", gdb incorrectly reads a > 64-bit value off of the pointer address, which is totally bogus and would not > be what gdb would do if it had debug info for a_loc(), in which case GDB would > know that it returns char *, and thus would deref only one byte and behave like > described above in the 1: 2: 3: steps. The behavior of the expression should not > change like that depending on whether you have debug info. Thus, GDB should error > out. This argument is compelling. You've convinced me. Kevin