From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by sourceware.org (Postfix) with ESMTPS id 837ED3858D3C for ; Thu, 14 Apr 2022 10:22:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 837ED3858D3C X-IronPort-AV: E=McAfee;i="6400,9594,10316"; a="287953473" X-IronPort-AV: E=Sophos;i="5.90,259,1643702400"; d="scan'208";a="287953473" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Apr 2022 03:22:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,259,1643702400"; d="scan'208";a="803083959" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by fmsmga006.fm.intel.com with ESMTP; 14 Apr 2022 03:22:54 -0700 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Thu, 14 Apr 2022 03:22:53 -0700 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27 via Frontend Transport; Thu, 14 Apr 2022 03:22:53 -0700 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.101) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.27; Thu, 14 Apr 2022 03:22:53 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i/H8VIdI6N4NDLJSpOHeHHN+9MPhSTwJ5S3RrOFNwj0DfGXHBlHLIKqIPK8qbf9f+PouCW04gJFBN9P7s4X80rR6aVrgR16wxQqanK6CPTG0O6ivuq92lGMDKeauHhjiTFSimV3Qv4iUmt92jpRkOmFjeOW7oO3hZWpQ14EcH+28kBI7A0dYZr7fQY5W8irbhcvUO7abOAV2waJOGu+J3qaTFr0O4qz0WIO2E7dzBjhIExhqoZ2G0OQ06iZ5OStE1TDvIDKdRpJB1Nwv0PtUyCTGwDWq7mfm32OVUAuRcFxOvwKkaUfzvtc2zzglbtwLIkEVllEs3bblPAgv6CbdAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VttpVIWxMHQApxLQxMWazaom1JNlKIqdqThtUOOmUAQ=; b=BrVklRmGGHGMi4LLR1NtQrsfxDPLshCHVQhC6bxBZIOd2XKEKWBXoGtv5a02vORaiwOrkVp3/cze+l1ToOUmaLZVaI57g9uX0O7WlM0OZaO7J4XIIYqouKaZONnRK5UTyTn40cPzy1PENogc2xNNrMzcNap9tLaHH35vrw1bkz/+V46w2azr7FJKgP84Y64PzSeiGbr1jw5JTEnv4rKbRBSvQ3Qo8w1n6SVhRVCONYuw5H9LZRXtN0rwaS/W0CxRMrM6iLjfKysxia+fQ/CKDJywMtiHlTudwQFQg8guTIMB/EqIvXn6OYBHLjchvSedFN/ahVd3SKp+n+0pniVhbw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from CY4PR1101MB2071.namprd11.prod.outlook.com (2603:10b6:910:1a::10) by PH0PR11MB5902.namprd11.prod.outlook.com (2603:10b6:510:14d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5144.29; Thu, 14 Apr 2022 10:22:52 +0000 Received: from CY4PR1101MB2071.namprd11.prod.outlook.com ([fe80::99b6:62d4:b384:998]) by CY4PR1101MB2071.namprd11.prod.outlook.com ([fe80::99b6:62d4:b384:998%5]) with mapi id 15.20.5144.029; Thu, 14 Apr 2022 10:22:52 +0000 From: "Kempke, Nils-Christian" To: Tom Tromey , Nils-Christian Kempke via Gdb-patches Subject: RE: [PATCH 2/2] gdb: Resolve dynamic target types of pointers. Thread-Topic: [PATCH 2/2] gdb: Resolve dynamic target types of pointers. Thread-Index: AQHYDG8c7kvyvhMx8kmJfwRdCntUeKyNVSWUgAjaHkA= Date: Thu, 14 Apr 2022 10:22:52 +0000 Message-ID: References: <20220118132626.3786176-1-nils-christian.kempke@intel.com> <20220118132626.3786176-3-nils-christian.kempke@intel.com> <87k0e2tsga.fsf@tromey.com> In-Reply-To: <87k0e2tsga.fsf@tromey.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.401.20 dlp-reaction: no-action x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b376e2d6-d902-4da6-3d88-08da1e00bb8f x-ms-traffictypediagnostic: PH0PR11MB5902:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6CYACtpLoSHPoo4QMLfGGz52gzYk8Z4F0TU543Gvjx/dll+i0tW6RHAwV87RGr+beGz5dPmBlp8pzlnoXU/WNnrBMCOrDhwUY1+2DVPtJh4x99Q+JmLuTb6QPnjIV2KIffNK9r5qkplgU3tGBMzAovTYyl5Sq6QM3QP9+PFSoytn3+KbX2PFJ4bzvyg4qjl5zWDAbvHq8AZ62qRu9G6GNMgluz8W6bBbOsDTpAOfzC9w5zkGc2ge5Ofll4lBh/ec+Az+oiBdPADsz+cgK+F7vlqajutL/b2j3TIuZFanWXSiZ698Vd5qGiv9nWLl/EvvQoEGwtJdi8mndz5rSAHrxvIa+OgtfZlEhT5UqbUuTX0p9LbZOhXGVW4xkLNsxZvzzdG8U3VzX81O4jnZZFL0CDs6/MZ69q8BZa9PrqwDVJvIP8CcrhblBhvt/JT41tVrEl7I8Jyy2RyuExwlmVvZyqtzUH2MTg+D35HGx9sem0k5dRnmJVyEMFJVs1V/B6s/I34vD+Slw6LqmPzvN4oYRG8p2Zf8BwhQfBR0FdpLZGPZK8oaL2rTwA79uir/g1V8s+HoVquwx9DBUNwm2zoAMJ5SB8wXYGOfnk1P1esdwmzrA+Qc9tMi3f7jKci8P38bRgZAZvVlyGqDg3UgQQCEmAu81Dw/UeHpdJOOmcyeP4rc0SuJrSxPcpdz78fuK6/bEFWlODjqIqtSzVzoLEh6ag== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR1101MB2071.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(53546011)(33656002)(55016003)(7696005)(5660300002)(186003)(8936002)(83380400001)(508600001)(316002)(76116006)(38100700002)(2906002)(71200400001)(66946007)(110136005)(86362001)(9686003)(8676002)(66476007)(66556008)(66446008)(64756008)(52536014)(6506007)(122000001)(38070700005)(82960400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 2 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?05jo73Wp0v9C9fHt8tkMqVy2b0lFmrhBIT/DV7zVi3aADfQWy0nL/QEVYOpt?= =?us-ascii?Q?Wp6qcjICPlVAX38FXTDXQuzlhEspGXd3VtbQ86FfgeyFPj7891i1OfmbResA?= =?us-ascii?Q?PWdB2kpXWbjF5g3yJk4gITuQCuuHYafSLqTxMZxm232Tl86pEVIZzeJgDciZ?= =?us-ascii?Q?WlsdAf/CuzfWcgfAcH9BhjdVm7al7N4FpVsPoG/1G6OkQgI7aCnifkPnbVhr?= =?us-ascii?Q?h2YKHCP5W5uC+Nw1E2fN63M9v4YZN3a0jZNfDEY3ZvBGvmQ7uo2fiA50EtVb?= =?us-ascii?Q?52kkfLIeKbsnkpQ1XVPqx0gQDxoCOzMn64KNU7ZI/4iFmbGnI11oA2ELUoef?= =?us-ascii?Q?tyiksNcDUSQkiez+/3ieYrkxJEhnC/U2nCgKPwkbjgBm4dFVjDYKTWVyxA5r?= =?us-ascii?Q?IfebL0AsVW1c/51gq7AiW5NUFOd6QXjiRJLnprEs8/7ogFQvPAal4VhD2Vch?= =?us-ascii?Q?sAtGlaEmz3G/CSV2JSZraDp+Uzf2c6hOQaMc3o37OCU7Y6asm1XPZRhqxOIW?= =?us-ascii?Q?PJbOdl7sTXBzDZoArKQ8HOSbEbB+UVuNALjcF7nCy+aKsLwr+wKBfeyy3oN9?= =?us-ascii?Q?DiJmRPOWMRfgcNqKNYC0bJr5egTVdWjTiZtsBNeJfV9+QQq+WFb3QG2CewC5?= =?us-ascii?Q?IpUqiXKefGZhda4tovAtoKKSk3oIgTjbIBYi3Y4cmRWIS2qMdtOAE0Jnb23y?= =?us-ascii?Q?RcMUvjI7dW1gtcV5OebY3zQKgURQGHXc5Gn7IoUyRa3VheMmPMR0Efv4uaO0?= =?us-ascii?Q?xjdw7pQJdqiBQbUZAKXO38MnDjOUgfwvjY/GQtM4lqy0WwjBi+Yf8QoyAyc7?= =?us-ascii?Q?UWtk+NupMNBCZdMpoHcRTzE2RgR7+pyuBr/lPHchlrHDl9ECSQMdrvcbIPTG?= =?us-ascii?Q?Y1ewaHXNb6Yya6zFF6rsbqIm10gnbwVRWyw7ZnHm1oob83QCneHepTMtEnmf?= =?us-ascii?Q?U1mriTHrUiWjE3GRwIDu9aTgMqIsAqAyH59U9HYCMRbIDl+2n8l0/altEuHz?= =?us-ascii?Q?bBT3NdpSONl08vz/RMzGs+LQ5quvOCxV6k82RbRJM8RcXaXN9nk24ecz5kpH?= =?us-ascii?Q?+y36ZcFxQZZnmsE1ZuLgdF58aRJA7EM9SWUVfNhg4xtXTP31TOyBGblCmKqx?= =?us-ascii?Q?QZpxxJutGQkvA306+ycbWpq86Y/eq1e0KtvM1o6ahANwEb4VVJv7cGJmEGkI?= =?us-ascii?Q?yUWIurOhqGwuSfCSsU9Rc2tLTbt+BAEocYsGdSNaBnX19NluYxnHAqGBDqyx?= =?us-ascii?Q?GWlxjTG8Y3OYZD35J2rHt6nsYbge+GL7S4y6ukUA8pk6jlf4lVW46X730EQm?= =?us-ascii?Q?8Md23DN0TyUWgBLSwhsQvWi9KnqrRSdD+kYHYcBnrzJCnhY/f3+H5Au7dWIb?= =?us-ascii?Q?AmC+rIR5KzhQumcS5Ul4kichLMz4HZTZoR7VxeLNluwzSg2t+rKdMxw/Rv0a?= =?us-ascii?Q?VxV8tm9oQaZqj7gedW2mxhR5rjVrgzR//JZczjGlCeOGEgwrHrW6hFn/0klL?= =?us-ascii?Q?/QTK4IXdkrBTUKIb4wekWGjXpY0VCQrKrJqfFCWqXpcpBfU7epy1F9RDoNYK?= =?us-ascii?Q?RKW1NggnCbZbnlDpDk7iJNgNxQqXhNehi8eiRTqIEBMUftC+TvRGFGLfmNWQ?= =?us-ascii?Q?VJXjt94CS5PMrplgob7E10+01ya84ZIBIpYmaKGTsOcK3CwcjdkBWRmPur87?= =?us-ascii?Q?1B0/7Gk80OqCopQLEh1XBAaYAuQbvknIW/jzT7z2KgBHcJXB108SBf+V2sOm?= =?us-ascii?Q?YU0+eSjKHiolu01KUnq7SFIrcBYog4Wr+nghGPyg9VC5nGVwixfE28Kf4RhG?= x-ms-exchange-antispam-messagedata-1: KOrXsuZp8ug/VfDMcmgclfsAO2fxzl6FMXg= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY4PR1101MB2071.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b376e2d6-d902-4da6-3d88-08da1e00bb8f X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2022 10:22:52.1125 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2G2uFfG3Dek1toUuCVCL1hatrU3gf7IqzT53q9nybOIc0RpRd4Lr/Gdi5vPUaMK+NjRLfnT8B68B48F2ZGPkQVJ5ewyWA6ce5zB+HOcW+0M= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5902 X-OriginatorOrg: intel.com Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 14 Apr 2022 10:22:58 -0000 Hi Tom, Thanks for the feedback. Sorry that it took me so long to reply - the mail somehow got lost.. > -----Original Message----- > From: Tom Tromey > Sent: Thursday, February 10, 2022 8:47 PM > To: Nils-Christian Kempke via Gdb-patches > Cc: Kempke, Nils-Christian > Subject: Re: [PATCH 2/2] gdb: Resolve dynamic target types of pointers. > = > >>>>> Nils-Christian Kempke via Gdb-patches patches@sourceware.org> writes: > = > Hi. Thanks for the patch. > = > > + if (type->code () =3D=3D TYPE_CODE_PTR && is_dynamic_type (type)) > > + { > > + CORE_ADDR addr; > > + if (nullptr !=3D TYPE_DATA_LOCATION (TYPE_TARGET_TYPE (type))) > > + addr =3D value_address (val); > > + else > > + addr =3D value_as_address (val); > = > This seems weird to me. When does value_as_address fail? > It seems to me that a value whose type is TYPE_CODE_PTR should be more > easily convertible to a CORE_ADDR without examining > TYPE_DATA_LOCATION. > = > The same thing applies in a couple more spots in the patch. > = This if else has been introduced because of the way ifort/icc describe poin= ters vs. gcc/gfortran and icx/ifx. For the simplified DWARF below I'll try and = omit non-useful entries. As an example I'll take a pointer to an array (which i= s what we want in the situation of dynamic target types I guess). Different from = gfortran and ifx the DWARF entry for a pointer in ifort is a <1> DW_TAG_variable <> DW_AT_type: <> DW_AT_location: (location of the pointer) <1> DW_TAG_pointer_type DW_AT_type: <1> DW_TAG_array_type <> DW_AT_type: <> DW_AT_data_location: (location of the array) <2> DW_TAG_subrange_type So, in ifort the DW_AT_location of the DW_TAG_variable is actually the location of the pointer variable and not the location of the array. Dereferencing this location then actually yields the location of the array.= And this location is then used in the DW_AT_data_location expression to retrieve the actual array. When printing such a pointer in gdb one will end up in the c_value_print function in c-valprint.c. Taking the value_as_address now fails - since it is not the address of the target_type but the address of the address of = the target_type. The same thing holds for dereferencing such a DWARF construct in value_ind in valops.c. = To resolve this, an additional check is added for the target_type's data_location. If the target type of a pointer does have a data_location, t= hen that one is being used as location of the underlying type. For gfortran and ifx the same pointer to array in Fortran is described as Fortran: <1> DW_TAG_variable <> DW_AT_type: <> DW_AT_location: (location of the pointer) = <1> DW_TAG_array_type <> DW_AT_type: <> DW_AT_data_location: (location of the array) <2> DW_TAG_subrange_type When printing this pointer to array in gfortran/ifx the pointer print funct= ion is not actually called - since the DWARF does not emit a pointer here. Instea= d, the normal array print is invoked which will use the DW_AT_data_location. So we do not run into this same problem > I'm curious why the code added here is not also needed in f-valprint.c. The reason here is simply that Fortran does not have this implemented for Itself. Instead the fortran f_langugage inherits from language_defn (the a= ll languages base class) which simply delegates the value-print to = c_value_print / so changing it there suffices. > = > > --- a/gdb/testsuite/gdb.cp/vla-cxx.exp > > +++ b/gdb/testsuite/gdb.cp/vla-cxx.exp > > @@ -23,6 +23,36 @@ if ![runto_main] { > > return -1 > > } > = > > +gdb_breakpoint [gdb_get_line_number "Before pointer assignment"] > > +gdb_continue_to_breakpoint "Before pointer assignment" > > + > > +set test_name "ptype ptr, Before pointer assignment" > > +gdb_test_multiple "ptype ptr" $test_name { > > + # gfortran > > + -re "=3D int \\(\\*\\)\\\[variable length\\\]\r\n$gdb_prompt $" { > > + pass $test_name > > + } > > + # ifort/ifx > = > This references fortran compilers but is a c++ test. > = Thanks, good spot - corrected in v2. > > +gdb_test "ptype ptr" "int \\(\\*\\)\\\[3\\\]" > > +gdb_test "print ptr" "\\(int \\(\\*\\)\\\[3\\\]\\) $hex" > > +gdb_test "print *ptr" " =3D \\{5, 7, 9\\}" > = > Do these pass with all compilers or do they also need to be conditional? > = These pass with all combinations I tried. The test has another failure for ifort but this one is not related to the actual ptype but some issue in the DWARF from ifort (print vlaref and print vlaref2 fail). But actually I noticed an error on my side - in fact (and as pointed out ab= ove) ifx and gfortran use similar DWARF to describe the above compiled test while ifort differs. So, the two cases for the conditional tests would be gfortran/ifx and ifort. I'll correct this in my second version. Maybe a word about what I tested: The compiler stacks I tested were gcc + gfortran, icc + icpc + ifort and icx + icpx + ifx (here a non-released version with some more bugfixes). My main focus laid on the GNU stack and here all test are passing. For any testing with ifx I had to also apply a not-yet-upstreamed patch since ifx uses a slightly different format for its emitted dwarf type name (so, e.g. the $int for ifx is different from ifort and gfortran). I intend to upstream this one soon to actually improve ifx pass rates. All modified test are passing for the GNU and any of the Intel stacks. For GNU I could not detect new issues in the rest of the testsuite - for the Intel stacks I only really tested the directly affected gdb.fortran and gdb.cp parts of the testsuite. I just rebased this patch to master but there were (nearly) no conflicts so= I'd want to resolve this discussion before sending a v2. Thanks, Nils Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva = Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928