From patchwork Tue Sep 20 07:26:25 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Kempke, Nils-Christian" X-Patchwork-Id: 55128 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CBECD385829F for ; Tue, 20 Sep 2022 07:27:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CBECD385829F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1663658825; bh=P/7m0z2JFvVp9i1vpSdXEMCbzcIWyDgMJL28Rk71LWE=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=wTa6psa8LXpUSi23nkjGYcdOKA+9NfFH9FBmUJX+EhHsE+458Pssc/Bed/mvbvf1O 2j9NV9bI634ryL7qvT4OgviQs2D1qc07+fe9pIk0LkI9q3/UfIPB9PS7YGxHadLEG6 WNtvq41+JA4iU5rbUXxR8Qw20wBSd2dVpiw/pn64= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by sourceware.org (Postfix) with ESMTPS id E05603858D37 for ; Tue, 20 Sep 2022 07:26:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E05603858D37 X-IronPort-AV: E=McAfee;i="6500,9779,10475"; a="298347302" X-IronPort-AV: E=Sophos;i="5.93,329,1654585200"; d="scan'208";a="298347302" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Sep 2022 00:26:37 -0700 X-IronPort-AV: E=Sophos;i="5.93,329,1654585200"; d="scan'208";a="618810691" Received: from labpcdell3650-003.iul.intel.com (HELO localhost) ([172.28.49.87]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Sep 2022 00:26:36 -0700 To: gdb-patches@sourceware.org Subject: [PATCH 0/4] Dynamic properties of pointers Date: Tue, 20 Sep 2022 09:26:25 +0200 Message-Id: <20220920072629.2736207-1-nils-christian.kempke@intel.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 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, SPF_HELO_NONE, SPF_NONE, 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-Patchwork-Original-From: Nils-Christian Kempke via Gdb-patches From: "Kempke, Nils-Christian" Reply-To: Nils-Christian Kempke Cc: tom@tromey.com Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" Hi, this series was partly posted to the mailing list before here: https://sourceware.org/pipermail/gdb-patches/2022-January/185233.html The original posting contained a different (probably much worse) version of patch 2 and 3 of this series: gdb, typeprint: fix pointer/reference typeprint for icc/ifort gdb/types: Resolve pointer types dynamically Back then it seems now that I had not fully understood what happened - thanks to Tom for his insightful review and comments! The originally posted series attempted to allow pointer types to be considered as dynamic types within GDB and tried to then resolve dynamic properties of pointers when e.g. printing them. This series, or rather patch 2 does mainly the same. It enables GDB to mark pointers that point to dynamic types (such as arrays) as dynamic types similar as it is already done for references. We tried to also have this new 'feature' for icc/icpc/ifort and ran into some problems, which caused the addition of Patch 1 and Patch 3. Patch 1 was added as the newer versions of icc emit a deprecated warning which is unexpected within the testsuite. Patch 3 was added because of the way icc/icpc/ifort emit references and pointers. Patch 3 was partly also visible in the original series - but it was poorly done there and not separated properly leading to much confusion. Patch 3 still seems a bit like a hack to me - but is also seemed reasonable to do it like this. If anyone has a better idea on patch 3 - I am happy to change it. I expect this part to be the most controversial. Patch 4 is just a small addition from the Fortran side, which also originally motivated this series. Fortran pointers can have the dynamic property DW_AT_associated - telling dynamically whether a pointer is associated or not. As we are now able to resolve dynamic properties we could also fix the sizeof intrinsic operator (Fortran allows for printing the size of a pointer-to-array) since we dynamically resolve array sizes of pointer-to-arrays. Any feedback is welcome! Cheers! Nils Bernhard Heckel (1): gdb/types: Resolve pointer types dynamically Nils-Christian Kempke (3): gdb, testsuite: handle icc and icpc deprecated remarks gdb, typeprint: fix pointer/reference typeprint for icc/ifort gdb/fortran: Fix sizeof intrinsic for Fortran gdb/eval.c | 3 + gdb/gdbtypes.c | 77 +++++++- gdb/testsuite/gdb.cp/vla-cxx.cc | 4 + gdb/testsuite/gdb.cp/vla-cxx.exp | 33 ++++ gdb/testsuite/gdb.dwarf2/dynarr-ptr.exp | 16 +- .../gdb.fortran/pointer-to-pointer.exp | 2 +- gdb/testsuite/gdb.fortran/pointers.exp | 178 ++++++++++++++++++ gdb/testsuite/gdb.fortran/pointers.f90 | 29 +++ gdb/testsuite/gdb.fortran/sizeof.exp | 110 +++++++++++ gdb/testsuite/gdb.fortran/sizeof.f90 | 108 +++++++++++ gdb/testsuite/lib/gdb.exp | 18 ++ gdb/valprint.c | 24 ++- 12 files changed, 582 insertions(+), 20 deletions(-) create mode 100644 gdb/testsuite/gdb.fortran/pointers.exp create mode 100644 gdb/testsuite/gdb.fortran/sizeof.exp create mode 100644 gdb/testsuite/gdb.fortran/sizeof.f90