From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 34F323839C7B for ; Thu, 6 May 2021 12:33:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 34F323839C7B Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 146CWvX6113896; Thu, 6 May 2021 08:33:15 -0400 Received: from ppma01fra.de.ibm.com (46.49.7a9f.ip4.static.sl-reverse.com [159.122.73.70]) by mx0a-001b2d01.pphosted.com with ESMTP id 38cg180yvg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 May 2021 08:33:14 -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 146CXCJR010462; Thu, 6 May 2021 12:33:12 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma01fra.de.ibm.com with ESMTP id 38bee88ftr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 May 2021 12:33:12 +0000 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 146CX94j29295042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 6 May 2021 12:33:09 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 40606AE053; Thu, 6 May 2021 12:33:09 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2D729AE04D; Thu, 6 May 2021 12:33:09 +0000 (GMT) Received: from oc3748833570.ibm.com (unknown [9.145.153.177]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP; Thu, 6 May 2021 12:33:09 +0000 (GMT) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id 92EB6D80276; Thu, 6 May 2021 14:33:08 +0200 (CEST) Date: Thu, 6 May 2021 14:33:08 +0200 From: Ulrich Weigand To: gcc@gcc.gnu.org, gdb@sourceware.org Cc: krebbel@linux.ibm.com Subject: Issue with pointer types marked with scalar_storage_order Message-ID: <20210506123308.GA27332@oc3748833570.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: uG1e-ZAg_v8_uEXfmTlTHxYaG9dGjOlR X-Proofpoint-GUID: uG1e-ZAg_v8_uEXfmTlTHxYaG9dGjOlR X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-06_08:2021-05-06, 2021-05-06 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 lowpriorityscore=0 clxscore=1011 impostorscore=0 mlxscore=0 spamscore=0 malwarescore=0 mlxlogscore=999 adultscore=0 bulkscore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2105060090 X-Spam-Status: No, score=-3.1 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: Thu, 06 May 2021 12:33:19 -0000 Hello, for a few years now, GCC has supported the scalar_storage_order attribute (and pragma) that allows specifying the storage order (endianness) of structures. This affects both the code GCC generates to access variables declared using the attribute, and also the debug info: GCC emits the DW_AT_endianity attribute to allow debuggers to work correctly with those variables as well. However, in one specific scenario this doesn't work correctly right now: pointer types. Currently, GCC *will* swap the storage order for members of pointer type in a structure declared using scalar_storage_order, but it will *not* emit DW_AT_endianity for these fields -- and it really cannot, because the DWARF standard allows DW_AT_endianity only for DW_TAG_base_type type entries and not for DW_TAG_pointer_type entries. I'm not really sure where exactly the bug is, because I'm not quite sure if pointer types actually *should* be byte swapped. On the one hand, the typical use case of scalar_storage_order is to simplify accessing binary data (read from a file or the network) that was generated on a "foreign" architecture that uses a different byte order. Those use cases are unlikely to involve any pointer types, since pointer values from a foreign system are typically not usable on the current system anyway. 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? If we do want to byte-swap pointer types, then I guess we need to still fix the debug info problem, which I guess would at a minimum require extending DWARF to allow DW_AT_endianity as an attribute to DW_TAG_pointer_type (and then probably also DW_TAG_reference_type, DW_TAG_rvalue_reference_type, DW_TAG_ptr_to_member_type and possibly others). Also, the implementation in GDB would need to be changed accordingly. Any comments or suggestions on what to do here? Thanks, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com