From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id xONHHmw2lWBbQgAAWB0awg (envelope-from ) for ; Fri, 07 May 2021 08:45:32 -0400 Received: by simark.ca (Postfix, from userid 112) id 6DB991F11C; Fri, 7 May 2021 08:45:32 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.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 5AA381E01F for ; Fri, 7 May 2021 08:45:31 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8A98F39AD842; Fri, 7 May 2021 12:45:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8A98F39AD842 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1620391530; bh=IWQLdOqw7oYQ7bGhkIsYWgr5j/ahfXVdYX23jTlX44c=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=QUVd1NUxhIw3VD1l62NzHuJXzzzS0OHSH8YLkXW4tQxA23ZzfUeD2qjkpWhXEQ6ow 70FQlLIYJ2+SoSlsuGZVCNTQQ+d547IXbnLXTjGC50BJsg4i9HC+2ZxoYWD5rPFZvu O23M9J7LfGWqByUOiEvXnKeGQWxNTqmdWmATiD50= Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 2A3DA393BC16 for ; Fri, 7 May 2021 12:45:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2A3DA393BC16 Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 147Ci0JD122652; Fri, 7 May 2021 08:45:24 -0400 Received: from ppma01fra.de.ibm.com (46.49.7a9f.ip4.static.sl-reverse.com [159.122.73.70]) by mx0b-001b2d01.pphosted.com with ESMTP id 38d5tk80t7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 May 2021 08:45:23 -0400 Received: from pps.filterd (ppma01fra.de.ibm.com [127.0.0.1]) by ppma01fra.de.ibm.com (8.16.0.43/8.16.0.43) with SMTP id 147CdWPd017474; Fri, 7 May 2021 12:45:22 GMT Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by ppma01fra.de.ibm.com with ESMTP id 38csqgr5ka-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 May 2021 12:45:21 +0000 Received: from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com [9.149.105.58]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 147CjJwZ16253210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 7 May 2021 12:45:19 GMT Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 661F24C04A; Fri, 7 May 2021 12:45:19 +0000 (GMT) Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 521424C040; Fri, 7 May 2021 12:45:19 +0000 (GMT) Received: from oc3748833570.ibm.com (unknown [9.145.71.10]) by d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 7 May 2021 12:45:19 +0000 (GMT) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id B5D63D802A1; Fri, 7 May 2021 14:45:18 +0200 (CEST) Date: Fri, 7 May 2021 14:45:18 +0200 To: Eric Botcazou , Tom Tromey Subject: Re: Issue with pointer types marked with scalar_storage_order Message-ID: <20210507124518.GA30859@oc3748833570.ibm.com> References: <20210506123308.GA27332@oc3748833570.ibm.com> <4620030.GXAFRqVoOG@fomalhaut> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4620030.GXAFRqVoOG@fomalhaut> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Proofpoint-GUID: YeWSSozHimplRww4TFV1lzkQDw15mo9G X-Proofpoint-ORIG-GUID: YeWSSozHimplRww4TFV1lzkQDw15mo9G X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-07_04:2021-05-06, 2021-05-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 bulkscore=0 phishscore=0 lowpriorityscore=0 mlxlogscore=999 suspectscore=0 spamscore=0 mlxscore=0 clxscore=1011 adultscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105070086 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Ulrich Weigand via Gdb Reply-To: Ulrich Weigand Cc: gcc@gcc.gnu.org, gdb@sourceware.org Errors-To: gdb-bounces@sourceware.org Sender: "Gdb" On Thu, May 06, 2021 at 04:07:52PM +0200, Eric Botcazou wrote: > > On the other hand, even the name of the attribute specifically > > refers to *scalar* types, and the C standard does classsify > > pointer types amongst the scalar type. So maybe this was > > originally intended? > > I don't think so, the feature was first implemented for Ada and, in Ada, > pointer types (called access types) are *not* scalar types. So this indeed > looks like a small oversight in the implementation. Ah, I see. > > Any comments or suggestions on what to do here? > > I'm going to conduct some testing in Ada but, barring unexpected fallout, I > would be in favor of changing the GCC implementation. It's presumably a 1- > line change in the reverse_storage_order_for_component_p predicate. Makes sense to me. Thanks for the quick fix! Tom Tromey wrote: > Ulrich> If we do want to byte-swap pointer types, then I guess we need > Ulrich> to still fix the debug info problem, which I guess would at a > Ulrich> minimum require extending DWARF to allow DW_AT_endianity as an > Ulrich> attribute to DW_TAG_pointer_type (and then probably also > Ulrich> DW_TAG_reference_type, DW_TAG_rvalue_reference_type, > Ulrich> DW_TAG_ptr_to_member_type and possibly others). Also, the > Ulrich> implementation in GDB would need to be changed accordingly. > > Ulrich> Any comments or suggestions on what to do here? > > This kind of extension is pretty normal in DWARF, so I think it isn't a > big deal to emit it. Consumers are ordinarily expected to simply ignore > things they don't understand. Given Eric's GCC change above, this is no longer necessary now. Thanks, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com