From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 From: Ulrich Weigand To: Eric Botcazou , Tom Tromey Cc: gcc@gcc.gnu.org, gdb@sourceware.org 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-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Fri, 07 May 2021 12:45:29 -0000 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