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 620A23858C2D for ; Tue, 27 Sep 2022 12:48:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 620A23858C2D 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 C7A161E0D3; Tue, 27 Sep 2022 08:48:10 -0400 (EDT) Message-ID: <55f9d383-76ff-4e2c-b5fe-495714bcbb8c@simark.ca> Date: Tue, 27 Sep 2022 08:48:10 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: [PATCH 3/4] gdb, typeprint: fix pointer/reference typeprint for icc/ifort Content-Language: en-US To: "Zaric, Zoran (Zare)" , "Kempke, Nils-Christian" , "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> <4369847e-1ca8-55fa-839e-95690e28ac05@simark.ca> From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.4 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: Tue, 27 Sep 2022 12:48:13 -0000 > The key difference here is that the DW_TAG_reference_type is a "standalone" type and there is always an object or a member (a physical location description) behind it while the DW_TAG_subrange_type is a by definition tied to a "standalone" array types. Unfortunately, it is not really meaningful to have an object of a DW_TAG_subrange_type so the type is more there to allow factorizing of the debug information. > > In the case of DW_TAG_reference_type, there is always an object that is the reference to something and if you dereference it, you get another object that the original object referenced, which is a very different case then the DW_TAG_subrange_type and the array type that references it. > > That being said, I don't believe that there is anywhere in DWARF stating that if there is an actual object of a DW_TAG_subrange_type type that the DW_OP_push_object_address operation (in any of the attributes of that type) should not use it, it just that the way how this type is defined doesn't really allow you to have a separate object of that type. Well, you can have a standaline DW_TAG_subrange_type object, in languages where you can define types to be subranges of other types. I just tried this Ada example: https://learn.adacore.com/courses/intro-to-ada/chapters/strongly_typed_language.html#subtypes And I got this, a variable with the subrange as its type: 0x00001a08: DW_TAG_subprogram DW_AT_name [DW_FORM_strp] ("greet") 0x00001a63: DW_TAG_subrange_type DW_AT_lower_bound [DW_FORM_data1] (0x05) DW_AT_upper_bound [DW_FORM_data1] (0x06) DW_AT_name [DW_FORM_strp] ("greet__weekend_days") DW_AT_type [DW_FORM_ref4] (0x00001a2a "greet__days") 0x00001a7b: DW_TAG_variable DW_AT_name [DW_FORM_string] ("s") DW_AT_type [DW_FORM_ref4] (0x00001a63 "greet__weekend_days") DW_AT_location [DW_FORM_exprloc] (DW_OP_fbreg -125) > At the end of the day, the definition of DW_OP_push_object_address operation just states that the operation pushes the address of the object currently being evaluated, It even states that it could be a component of an object, but it still has to be something tangible (a real location). I think that the confusion comes from the fact that DW_TAG_subrange_type can serve two different and unrelated purposes. One as a standard standalone type, as shown above. And two, as a direct child of a DW_TAG_array_type, used to express the bounds. Section 5.5 - Array Type Entries says: Each array dimension is described by a debugging information entry with either the tag DW_TAG_subrange_type or the tag DW_TAG_enumeration_type. These entries are children of the array type entry and are ordered to reflect the appearance of the dimensions in the source program (that is, leftmost dimension first, next to leftmost second, and so on). My interpretation of this text is that it describes that second special use case where DW_TAG_subrange_type describes the bounds of the array, but does not represent a concrete object itself, as it would with its first purpose. As Zoran said, maybe this helped "factorize" the debug information and make the DWARF committee write less text, but I think it also adds confusion. I think it should be interpreted as if the DW_TAG_array_type had the DW_AT_{lower,upper}_bound attributes directly. I think this is what is intended by the standard, looking at the D.2.1 example. The comments on the DW_AT_{lower,upper}_bound expressions show that they consider DW_OP_push_object_address to have pushed the array's address. That said, assuming that this is indeed "broken" DWARF, icc/ifort produce what they produce, and I am open to make GDB handle it. We work around broken DWARF all the time for different compilers. However, the commit message would need to explain this, the code should make it clear that this is a workaround for a specific form of DWARF emitted by icc/ifort, and ideally gated behind a compiler check. This way, in 20 years, when we decide we no longer want to support 20 year old hacks, it's easy to identify and remove them. It would also be good to have a gdb.dwarf2 test case for this, explaining that "this is not really valid DWARF but we want to support it anyway". Simon