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 873ED383F96C for ; Thu, 9 Jun 2022 17:24:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 873ED383F96C Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 259GlYx2003233; Thu, 9 Jun 2022 17:24:01 GMT Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3gkmps0nxd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Jun 2022 17:24:01 +0000 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 259H5Onr014936; Thu, 9 Jun 2022 17:24:00 GMT Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by ppma04dal.us.ibm.com with ESMTP id 3gfy1ambdp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Jun 2022 17:24:00 +0000 Received: from b03ledav006.gho.boulder.ibm.com (b03ledav006.gho.boulder.ibm.com [9.17.130.237]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 259HNxWr32440576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 9 Jun 2022 17:23:59 GMT Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9FD55C605A; Thu, 9 Jun 2022 17:23:59 +0000 (GMT) Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 528FDC6057; Thu, 9 Jun 2022 17:23:59 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.211.124.91]) by b03ledav006.gho.boulder.ibm.com (Postfix) with ESMTP; Thu, 9 Jun 2022 17:23:59 +0000 (GMT) Message-ID: <17e5bd9e5680588b0442206e67e09684a342a37a.camel@us.ibm.com> From: Carl Love To: Joel Brobecker , cel@us.ibm.com, gdb-patches@sourceware.org Date: Thu, 09 Jun 2022 10:23:58 -0700 In-Reply-To: References: <4d733e3a7a609709be1613359e7c91db869099ac.camel@us.ibm.com> <0b8f207eb10a8a339825478fb94f781a827321ac.camel@us.ibm.com> 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-GUID: SXXH3UmhyU1Xcu1gxwwqXqJw41nFUaHX X-Proofpoint-ORIG-GUID: SXXH3UmhyU1Xcu1gxwwqXqJw41nFUaHX Subject: RE: [PATCH] Powerpc, fix vla-optimized-out.exp test 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-09_12,2022-06-09_02,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 suspectscore=0 bulkscore=0 mlxlogscore=999 phishscore=0 lowpriorityscore=0 priorityscore=1501 clxscore=1011 adultscore=0 mlxscore=0 malwarescore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000 definitions=main-2206090064 X-Spam-Status: No, score=-4.8 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: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2022 17:24:04 -0000 Joel: I have been talking with the gcc developers to understand more about how DWARF reports the type and size of the variable in the DWARF output to answer your question below. On Sun, 2022-04-17 at 08:19 -0700, Joel Brobecker wrote: > Hello Carl, > > Thanks for the patch. > > > Powerpc, fix vla-optimized-out.exp test > > > > The size of the variable a is not optimized out on Intel inspite of > > the > > use of the variable use being optimized out. > > > > On Powerpc, the use of variable a and the size of variable a are > > both > > optimized out. > > For me, it would be useful to include an annotated copy of the DWARF > info being produced on x86_64-linux where the size is available, > vs the DWARF being produced on PowerPC. This will help understand > what's happening and confirm that it is indeed valid for GDB to > print that the size has been optimized out I am still learning the DWARF format but here is what I have from my discussions. The dwarf is for the vla-optimized-out.c program compiled with -O1 which corresponds to the case where the message gets printed. Contents of the .debug_info section: Compilation Unit @ offset 0x0: Length: 0xef (32-bit) Version: 5 Unit Type: DW_UT_compile (1) Abbrev Offset: 0x0 Pointer Size: 8 <0>: Abbrev Number: 2 (DW_TAG_compile_unit) DW_AT_producer : (indirect string, offset: 0x3e): GNU C17 11.2.1 20220127 (Red Hat 11.2.1-9) -msecure-plt -mtune=power9 -mcpu=power9 -g -O1 -fno-stack-protector <11> DW_AT_language : 29 (C11) <12> DW_AT_name : (indirect string, offset: 0xb2): /.../gdb/testsuite/gdb.base/vla-optimized-out.c <16> DW_AT_comp_dir : (indirect string, offset: 0x0): /.../gdb/testsuite <1a> DW_AT_low_pc : 0x1000068c <22> DW_AT_high_pc : 0x5c <2a> DW_AT_stmt_list : 0x0 <1><2e>: Abbrev Number: 3 (DW_TAG_subprogram) <2f> DW_AT_external : 1 <2f> DW_AT_name : (indirect string, offset: 0xad): main <33> DW_AT_decl_file : 1 <34> DW_AT_decl_line : 37 <35> DW_AT_decl_column : 1 <36> DW_AT_prototyped : 1 <36> DW_AT_type : <0x7d> <3a> DW_AT_low_pc : 0x100006a0 <42> DW_AT_high_pc : 0x48 <4a> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <4c> DW_AT_call_all_calls: 1 <4c> DW_AT_sibling : <0x7d> <2><50>: Abbrev Number: 4 (DW_TAG_variable) <51> DW_AT_name : j <53> DW_AT_decl_file : 1 <54> DW_AT_decl_line : 39 <55> DW_AT_decl_column : 16 <56> DW_AT_type : <0x84> <5a> DW_AT_location : 2 byte block: 91 70 (DW_OP_fbreg: -16) <2><5d>: Abbrev Number: 5 (DW_TAG_variable) <5e> DW_AT_name : i <60> DW_AT_decl_file : 1 <61> DW_AT_decl_line : 40 <62> DW_AT_decl_column : 7 <63> DW_AT_type : <0x7d> <67> DW_AT_location : 0x10 (location list) <6b> DW_AT_GNU_locviews: 0xc <2><6f>: Abbrev Number: 6 (DW_TAG_call_site) <70> DW_AT_call_return_pc: 0x100006c4 <78> DW_AT_call_origin : <0x89> <2><7c>: Abbrev Number: 0 <1><7d>: Abbrev Number: 7 (DW_TAG_base_type) <7e> DW_AT_byte_size : 4 <7f> DW_AT_encoding : 5 (signed) <80> DW_AT_name : int <1><84>: Abbrev Number: 8 (DW_TAG_volatile_type) <85> DW_AT_type : <0x7d> <1><89>: Abbrev Number: 9 (DW_TAG_subprogram) <8a> DW_AT_external : 1 <8a> DW_AT_name : f1 <8d> DW_AT_decl_file : 1 <8e> DW_AT_decl_line : 29 <8f> DW_AT_decl_column : 1 <90> DW_AT_prototyped : 1 <90> DW_AT_type : <0x7d> <94> DW_AT_low_pc : 0x1000068c <9c> DW_AT_high_pc : 0x14 DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) DW_AT_call_all_calls: 1 DW_AT_sibling : <0xc7> <2>: Abbrev Number: 10 (DW_TAG_formal_parameter) DW_AT_name : i DW_AT_decl_file : 1 DW_AT_decl_line : 29 DW_AT_decl_column : 9 DW_AT_type : <0x7d> DW_AT_location : 0x20 (location list) DW_AT_GNU_locviews: 0x1c <2>: Abbrev Number: 11 (DW_TAG_variable) DW_AT_name : a <- Variable a, array of (unsigned char) DW_AT_decl_file : 1 DW_AT_decl_line : 31 DW_AT_decl_column : 8 DW_AT_type : <0xc7> <- a is type entry c7 <2>: Abbrev Number: 0 <1>: Abbrev Number: 12 (DW_TAG_array_type) <- array type entry DW_AT_type : <0xeb> <- array element type eb DW_AT_sibling : <0xe4> <2>: Abbrev Number: 13 (DW_TAG_subrange_type) DW_AT_type : <0xe4> From what I was told, the following DW_AT_upper_bound gives the upper bound for calculating the size of the array. I believe the size is given by (upper-bound (13) + 1 - lower bound(default 0)) * size of base type (8) = 112 The program declares char a[6] so I would expect the size to be 6 bytes not 112. Either way, it does look like the info is there, not that I claim to completely understand the DWARF output. Am I missing something which results in gdb saying the size is optimized out? DW_AT_upper_bound : 13 byte block: a3 1 53 23 1 8 20 24 8 20 26 31 1c (DW_OP_entry_value: (DW_OP_reg3 (r3)); DW_OP_plus_uconst: 1; DW_OP_const1u: 32; DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra; DW_OP_lit1; DW_OP_minus) <2>: Abbrev Number: 0 <1>: Abbrev Number: 1 (DW_TAG_base_type) DW_AT_byte_size : 8 DW_AT_encoding : 7 (unsigned) DW_AT_name : (indirect string, offset: 0x2c): long unsigned int <1>: Abbrev Number: 1 (DW_TAG_base_type) Here is the base type DW_AT_byte_size : 1 DW_AT_encoding : 8 (unsigned char) DW_AT_name : (indirect string, offset: 0x127): char <1>: Abbrev Number: 0 Carl