From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by sourceware.org (Postfix) with ESMTPS id E4D3D385734D for ; Thu, 23 Jun 2022 14:19:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E4D3D385734D Received: by mail-pj1-x1030.google.com with SMTP id go6so14150849pjb.0 for ; Thu, 23 Jun 2022 07:19:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=mDsYROyYjQM806EornE/1WpFpTRBaleBRImhyT+M/9c=; b=j7KAVo5ROj89tg1M9px18d0+owlgbFbkxNfB4pwnPhK1MWtMBMIB23SqbV+J1ebDrp 2K3nNMXLDn5IXxs2UdpJLWXpOtW4T9nHKNEUV2amCgtWQanSn/x4yM4M0oNgqrnCgzQ6 Oh/0snU6HpQ3kWWnWBu9RHbfBY6Pd8ekjiSW16hevusNFxbrXF/jcpD/eh7w9c4QtMiD FMW2l/aZpwq31rRMBbg53ViTqwE+PTZ4Jr9Caa34CnbKOPn8kaUCCHDNcTMev8xeTfQ/ r8HVkSO6tAIPNrvRyWc3gDhAWXwm7iZDyGn1RH6UIZ7vDQWXZ+seO3DFuOrz0yzqH0Cf tZcA== X-Gm-Message-State: AJIora8IerI9mm42cHNvyaTb18EDTPz1p/CwhUjpsTepoXT4HFASc7SH QuwebpYacEhlvZIBjRpNvg6A X-Google-Smtp-Source: AGRyM1uKu8/7jvkeCmDkKaP4biWu5da+9HrO3faOEhvmwu3nK6WIUMIctFBv41/E3ZdE39uLtP5JwA== X-Received: by 2002:a17:90b:4f8d:b0:1ec:af3b:d813 with SMTP id qe13-20020a17090b4f8d00b001ecaf3bd813mr4342360pjb.2.1655993978888; Thu, 23 Jun 2022 07:19:38 -0700 (PDT) Received: from takamaka.home ([184.69.131.86]) by smtp.gmail.com with ESMTPSA id p10-20020a170902780a00b0015e8d4eb273sm5681962pll.189.2022.06.23.07.19.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 07:19:38 -0700 (PDT) Received: by takamaka.home (Postfix, from userid 1000) id 580ABA4A97; Thu, 23 Jun 2022 07:19:37 -0700 (PDT) Date: Thu, 23 Jun 2022 07:19:37 -0700 From: Joel Brobecker To: Carl Love Cc: Joel Brobecker , gdb-patches@sourceware.org, will schmidt Subject: Re: [PATCH] Powerpc, fix vla-optimized-out.exp test Message-ID: References: <4d733e3a7a609709be1613359e7c91db869099ac.camel@us.ibm.com> <0b8f207eb10a8a339825478fb94f781a827321ac.camel@us.ibm.com> <17e5bd9e5680588b0442206e67e09684a342a37a.camel@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17e5bd9e5680588b0442206e67e09684a342a37a.camel@us.ibm.com> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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, 23 Jun 2022 14:19:42 -0000 Hi everyone, On Thu, Jun 09, 2022 at 10:23:58AM -0700, Carl Love wrote: > 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. Thanks Carl. Could someone else take a look and help Carl? I've been meaning to get to this, but haven't been able to get to this, not even on weekends, and I don't see myself having time for quite a while, unfortunately :-(. > > 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 > > -- Joel