From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id AA7383858C00 for ; Mon, 26 Sep 2022 16:02:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AA7383858C00 Received: from [10.0.0.11] (unknown [217.28.27.60]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 1F1601E0D3; Mon, 26 Sep 2022 12:02:09 -0400 (EDT) Message-ID: <4369847e-1ca8-55fa-839e-95690e28ac05@simark.ca> Date: Mon, 26 Sep 2022 12:02:09 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH 3/4] gdb, typeprint: fix pointer/reference typeprint for icc/ifort Content-Language: en-US To: Nils-Christian Kempke , gdb-patches@sourceware.org Cc: tom@tromey.com References: <20220920072629.2736207-1-nils-christian.kempke@intel.com> <20220920072629.2736207-4-nils-christian.kempke@intel.com> From: Simon Marchi In-Reply-To: <20220920072629.2736207-4-nils-christian.kempke@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP 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: Mon, 26 Sep 2022 16:02:12 -0000 On 2022-09-20 03:26, Nils-Christian Kempke via Gdb-patches wrote: > Intel classic compilers (icc/icpc/ifort) for references and pointers > to arrays generate DWARF that looks like > > <2><17d>: Abbrev Number: 22 (DW_TAG_variable) > <17e> DW_AT_decl_line : 41 > <17f> DW_AT_decl_file : 1 > <180> DW_AT_name : (indirect string, offset: 0x1f1): vlaref > <184> DW_AT_type : <0x214> > <188> DW_AT_location : 2 byte block: 76 50 > (DW_OP_breg6 (rbp): -48) > ... > <1><214>: Abbrev Number: 12 (DW_TAG_reference_type) > <215> DW_AT_type : <0x219> > <1><219>: Abbrev Number: 27 (DW_TAG_array_type) > <21a> DW_AT_type : <0x10e> > <21e> DW_AT_data_location: 2 byte block: 97 6 > (DW_OP_push_object_address; DW_OP_deref) > <2><221>: Abbrev Number: 28 (DW_TAG_subrange_type) > <222> DW_AT_upper_bound : <0x154> > <2><226>: Abbrev Number: 0 > > (for pointers replace the DW_TAG_reference_type with a > DW_TAG_pointer_type). This is, to my knowledge, allowed and corret DWARF > but posed a problem in GDB. Usually, GDB would deal with gcc references > (or pointers) that look like > > <2><96>: Abbrev Number: 8 (DW_TAG_variable) > <97> DW_AT_location : 2 byte block: 91 50 > (DW_OP_fbreg: -48) > <9a> DW_AT_name : (indirect string, offset: 0x2aa): vlaref > <9e> DW_AT_decl_file : 3 > <9f> DW_AT_decl_line : 41 > DW_AT_type : <0x1de> > ... > <1><1de>: Abbrev Number: 17 (DW_TAG_reference_type) > <1df> DW_AT_type : <0x1e3> > <1><1e3>: Abbrev Number: 22 (DW_TAG_array_type) > <1e4> DW_AT_type : <0x1bf> > <2><1e8>: Abbrev Number: 23 (DW_TAG_subrange_type) > <1e9> DW_AT_type : <0x1f2> > <1ed> DW_AT_count : <0x8a> > <2><1f1>: Abbrev Number: 0 > > The DWARF above describes a reference with an address. At the address > of this reference, so evaluating what lies at the DW_AT_location of the > DW_TAG_variable, we find the address we need to use to resolve the > array under the reference and print the array's values. > This is also exactly what GDB does per default when printing a > reference-to-array type. It evaluates the reference, and then takes that > address to resolve the array (implicitly assuming that the value of the > reference coincides with the address of the array). > > The difference to the icc output is icc's usage of DW_AT_data_location. > This attribute can be used to specify a location for the actual data of > an array that is different from the object's address. If it is present > in addition to a DW_AT_location (as is the case above) the array values > are actually located at whatever DW_AT_data_location is evaluated to > and not at the address DW_AT_location of the variable points to. > > When dealing with the icc output this posed a problem in GDB. It would > still evaluate the reference. It would then forget all about the reference > and use the address obtained that way to resolve the array type (which, > as mentioned, works fine with the gcc output). It would then discover the > DW_AT_data_location attribute in the array's DIE and it would try to > resolve it. > Here is where GDB ran into a problem: according to DWARF5 and as seen in > this example as well, DW_AT_data_location usually starts with a > DW_OP_push_object_address. This operation pushes the address of the > object currently being evaluated on the stack. The object currently being > evaluated however in this case is the reference, not the > array. This is where I block. My understanding is that the DW_OP_push_object_address within the array's DIE always pushes the address of the array variable itself. Regardless of where we are coming from. Evaluating the reference involves evaluating the array, now the "current" object is the array. This DWARF, that you quoted above: <1><219>: Abbrev Number: 27 (DW_TAG_array_type) <21a> DW_AT_type : <0x10e> <21e> DW_AT_data_location: 2 byte block: 97 6 (DW_OP_push_object_address; DW_OP_deref) Would make sense if the array variable itself was a descriptor whose first field is a pointer to the actual array data. The DW_OP_deref would read that pointer and push it on the the stack. But if no array descriptor is used (the array variable is the data directly), then either no DW_AT_data_location should be used, or a DW_AT_data_location consisting of only DW_OP_push_object_address should be used). The DW_AT_data_location including a DW_OP_deref is not meant to deal with the fact that the array is accessed through another DIE that is a reference. This is my understanding after reading section D.2.1 (Fortran Simple Array Example) in DWARF5. Simon