From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 8D2BF397EC26 for ; Wed, 8 Jun 2022 19:59:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8D2BF397EC26 Received: from pps.filterd (m0127361.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 258JP7V8021005 for ; Wed, 8 Jun 2022 19:59:00 GMT Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3gk1w9ghrq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 08 Jun 2022 19:58:59 +0000 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 258JpPwF007704 for ; Wed, 8 Jun 2022 19:58:59 GMT Received: from b03cxnp07029.gho.boulder.ibm.com (b03cxnp07029.gho.boulder.ibm.com [9.17.130.16]) by ppma02dal.us.ibm.com with ESMTP id 3gfy1avq8a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 08 Jun 2022 19:58:59 +0000 Received: from b03ledav002.gho.boulder.ibm.com (b03ledav002.gho.boulder.ibm.com [9.17.130.233]) by b03cxnp07029.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 258JwwuD36635044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 8 Jun 2022 19:58:58 GMT Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 07B57136051; Wed, 8 Jun 2022 19:58:58 +0000 (GMT) Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C6C0A136053; Wed, 8 Jun 2022 19:58:57 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.211.57.135]) by b03ledav002.gho.boulder.ibm.com (Postfix) with ESMTP; Wed, 8 Jun 2022 19:58:57 +0000 (GMT) Message-ID: <848a436ef86a2f3f12e291dcbbf58a89084a6053.camel@us.ibm.com> Subject: DWARF question about size of a variable From: Carl Love To: gcc@gcc.gnu.org, cel@us.ibm.com Date: Wed, 08 Jun 2022 12:58:57 -0700 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: JjwE0fn5RCz4Wi4_qIv7hE-XvFtg44jU X-Proofpoint-GUID: JjwE0fn5RCz4Wi4_qIv7hE-XvFtg44jU X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.874,Hydra:6.0.517,FMLib:17.11.64.514 definitions=2022-06-08_05,2022-06-07_02,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 spamscore=0 impostorscore=0 suspectscore=0 priorityscore=1501 lowpriorityscore=0 phishscore=0 adultscore=0 mlxlogscore=726 clxscore=1011 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000 definitions=main-2206080075 X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2022 19:59:01 -0000 GCC developers: Is there dwarf information that gives the size of a variable? I have a test case which when run on Intel gdb can print the size of an optimized out variable. However on PowerPC, gdb says the size information for the variable is optimized out. Is there some DWARF information that I can print on the Intel binary that shows the size information for the variable even though the variable is optimized out? Then by comparison on PowerPC I would expect the DWARF information would either say the size of the variable is optimized out or there is no information available. Here is the test program for the test. #include "../lib/attributes.h" int #ifdef NOCLONE __attribute__((noinline,weak)) ATTRIBUTE_NOCLONE #else __attribute__((noinline,weak)) #endif f1 (int i) { char a[i + 1]; a[0] = 5; return a[0]; } int main (void) { volatile int j; int i = 5; asm volatile ("" : "=r" (i) : "0" (i)); j = f1 (i); return 0; } So when the above test program is compiled with -03 and run on Intel we have the following: (gdb) break f1 Breakpoint 1 at 0x1150: file /.../gdb/testsuite/gdb.base/vla-optimized-out.c, line 30. (gdb) r Starting program: /.../gdb/testsuite/outputs/gdb.base/vla-optimized-out/vla-optimized-out-o3 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, f1 (i=5) at /.../gdb/testsuite/gdb.base/vla-optimized-out.c:30 30 { (gdb) p a $1 = (gdb) p sizeof( a) $2 = 6 <- the variable is optimized out but apparently the size info is still accessible When I compile and run the same program on PowerPC: (gdb) break f1 Breakpoint 1 at 0x100006e0: file /.../gdb/testsuite/gdb.base/vla-optimized-out.c, line 33. (gdb) r Starting program: /home/carll/GDB/build-current/.../vla-optimized-out-3 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, f1 (i=5) at /.../gdb/testsuite/gdb.base/vla-optimized-out.c:33 33 return a[0]; (gdb) p a $1 = (gdb) p sizeof (a) $2 = <- the variable is optimized out and the size is not available. Anyway, I am looking for some DWARF info on Intel and PowerPC which will show why Intel can display the size of the variable but PowerPC can not. Thanks for you help. Carl Love