From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 7aXyGhLik2DnIQAAWB0awg (envelope-from ) for ; Thu, 06 May 2021 08:33:22 -0400 Received: by simark.ca (Postfix, from userid 112) id 5E7911F11C; Thu, 6 May 2021 08:33:22 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.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 84CB51E01F for ; Thu, 6 May 2021 08:33:21 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B4CF73AA9905; Thu, 6 May 2021 12:33:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B4CF73AA9905 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1620304400; bh=P+Va0z6QvSz/vt52/qDSViYCUeTTLkUlS4CsF+qOfNE=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=SyqBLQLis/nZRX9pvtyqU0w2FMVqdedLqw8HMqVdHopDRSxiGn06dT77B1bzpqdvn 3P+mT7zFrvS+i1AQb20wOj1RQN/xKi08lS6bqzdczli3PP2nAtjvF2dcUAdBY0eXkA GdBcAmID6BI5EMHowtSrejJExbfsZE/rXrhvleg0= 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 To: gcc@gcc.gnu.org, gdb@sourceware.org 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-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: krebbel@linux.ibm.com Errors-To: gdb-bounces@sourceware.org Sender: "Gdb" 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