From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2048.outbound.protection.outlook.com [40.107.92.48]) by sourceware.org (Postfix) with ESMTPS id DACE13858D28 for ; Fri, 5 Nov 2021 11:39:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DACE13858D28 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L2X5bTefqkz5pZNdUUT/Uyi1INj+K68DdOGvGdvQwWrLsTPkOnNS3iOrlTYQ9u7YON6qs+9/pJLFg3/3z0hPHQAkJXi91iTB2OEjZDkjRCxGwSoO5xJYNYPGtPgCZNWYpfi8rUhEcDsnDuOpkLK2rbtfjCm5ExCqFwy+QYEo0tQkh0qR2M/FyiBe2eo/mixlTVbsSj4gc1x1Q+Y8m551VJVoIhvNZYAsidPFywO/FCu43vvWDY/HpugDHqpC9lw+uvQQDxlK61lkZ1f1cpF01Sw5cBF/k1sUc7NdyH386TeF5rnyxE0qwXQ+QO1KdFUEqmckCE9oWuh7UmWnD6xwkg== 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=Gpx1ulXsImDUdEzwa9NHhcU6E0JqIWChbs6TvCLa9hM=; b=T9YQiG7x/IizXzjStAP+UF+PvrNinmRnOWNVhsGEUWe49mMXanePIzjL/HS+Jv4+ZJiO7we+aTbA9bwiNEwAbdWt0/nFgbl2LHT8lKwwqDdkjDmn0K68+PaoiOzMWezxkS00pa2hYLippiWq3SQ6+Z21rjoWHrvNql82CWRbi3vuWIP3VxUosf7c8msG717MPU1dTg9jEUX4+oZYTft5LPDh/uN+Tm6w5gJZI9/6L1m+OYe4yQJKPfKYvlppm6ZeaPf100MGd+SEqwOiwTQdUT0CtNIKWAAVYbB7kkNkTAfLSrtxGPq8oCp78k91QhgXp6KCNm/TOzDpYso7j8EpQA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=sourceware.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none Received: from MW4PR04CA0162.namprd04.prod.outlook.com (2603:10b6:303:85::17) by DM6PR12MB4356.namprd12.prod.outlook.com (2603:10b6:5:2aa::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.10; Fri, 5 Nov 2021 11:39:07 +0000 Received: from CO1NAM11FT047.eop-nam11.prod.protection.outlook.com (2603:10b6:303:85:cafe::73) by MW4PR04CA0162.outlook.office365.com (2603:10b6:303:85::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.11 via Frontend Transport; Fri, 5 Nov 2021 11:39:07 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; sourceware.org; dkim=none (message not signed) header.d=none;sourceware.org; dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; Received: from SATLEXMB04.amd.com (165.204.84.17) by CO1NAM11FT047.mail.protection.outlook.com (10.13.174.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.4669.10 via Frontend Transport; Fri, 5 Nov 2021 11:39:07 +0000 Received: from localhost.localdomain (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Fri, 5 Nov 2021 06:39:05 -0500 From: Zoran Zaric To: Subject: [PATCH v4 00/28] Allow location description on the DWARF stack Date: Fri, 5 Nov 2021 11:38:21 +0000 Message-ID: <20211105113849.118800-1-zoran.zaric@amd.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 07404d85-d974-4930-c225-08d9a050e05d X-MS-TrafficTypeDiagnostic: DM6PR12MB4356: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: fualjtkUcBs+rMkBYaaN8RaWTq9P6mPg4IKEq0llUby/YHM/7JdUMux1LB7ey8Z7sRy6lgwjidsNCeZ3Fu4ZF/wPIR8idnM6Lc/i0uX3ftVSGRHCWhX0UICam0auiOiGAEPOXgWEddL6K+n+LuV83ADH+zdTDqNDZNnqTPWkl9iWPNZJY7BXcvrErO2HtehvQp1A+47l0HOSxhbPKAOKpdsdH/XSTb2aHWdHOKx9B1IytJhYU+Rb7l4OTNJ5do3q2dUJ4creaqtYd27W+tAMD6RS3S3IquKLHiowI1E7aFKTFiOB0rys6IahyB1igx/uGLk2M01FIuY1wmPtfLd+O0csmg4RalsKktlz/v2VcXhXFMSQB3zuVTn5UsXlYO0zx2lzOA29tTqs7y5cCMYrXeiJIghLJyU/rVKZHO8JBwbRoqcpi8ufU9yJ3mV/K58nJmHJCTXjn72oTCvOlxTvVd6I6eSMsT+o+exPTrHyaTm8eLPCKgxGjSwVQwuPVYJHEd+tuZHMHtIXNeYffhLgwPiWkjf6eKqoKyGBtXABxXXpzmNVgLH4hqrR9b9kyvAIEI8zEUHpbM3GHvahj7qnib/X9gRXGwYrTs5KCrM1LFwemjXKNfGMTDUx3/me2AJzVZSq2mW6bDLEPi1nu2gubfdIAJ9sqNWooIUiaJrYA5H5uR6CKEFwEBf0nBxYxYzV8+zL+f4eWTBH+vjsY16Kk2Ud0idS5xlLMC2LWIlbVkubsmNmFeqIL7mDyYxTigCmneQd+289SIcmoeBnj9PVXYrdLPtriIQsV76BQXtEvEDZ7EopLu1hVUeWCOMxCZ9W X-Forefront-Antispam-Report: CIP:165.204.84.17; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:SATLEXMB04.amd.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(4636009)(46966006)(36840700001)(966005)(36860700001)(6666004)(86362001)(4326008)(508600001)(356005)(81166007)(47076005)(2906002)(316002)(1076003)(83380400001)(70586007)(82310400003)(336012)(44832011)(2616005)(70206006)(426003)(8676002)(6916009)(16526019)(5660300002)(36756003)(8936002)(26005)(186003)(36900700001); DIR:OUT; SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Nov 2021 11:39:07.0015 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 07404d85-d974-4930-c225-08d9a050e05d X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d; Ip=[165.204.84.17]; Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CO1NAM11FT047.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4356 X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP 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: Fri, 05 Nov 2021 11:39:12 -0000 Based on gdb master: c5967f38de59c7375970c09b2c8b8702a01eb9d2 The idea of this patch series is to allow a future extensions of the DWARF expression evaluator needed for the upcoming vendor specific DWARF extensions. Main motivation behind this series of patches is AMD’s effort to improve DWARF support for heavily optimized code, but more specifically, optimized code for SIMD and SIMT architectures. These patches are part of the AMD’s DWARF standard extensions that can be found at: https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html While trying to support optimized code for these architectures, we found couple of restriction imposed by the version 5 of the standard: - CFI describes restoring callee saved registers that are spilled. Currently CFI only allows a location description that is a register, memory address, or implicit location description. AMDGPU optimized code may spill scalar registers into portions of vector registers. This requires extending CFI to allow any location description. - Optimized code may need to describe a variable that resides in pieces that are in different kinds of storage which may include parts that are in different kinds of memory address spaces. DWARF has the concept of segment addresses. However, the segment cannot be specified within a DWARF expression, which is only able to specify the offset portion of a segment address. The segment index is only provided by the entity that specifies the DWARF expression. Therefore, the segment index is a property that can only be put on complete objects, such as a variable. Another problem is with DWARF DW_OP_xderef* operations, which allow a value to be converted into an address of a specified address space which is then read. But it provides no way to create a memory location description for an address in the non-default address space. - DW_OP_breg* treats the register as containing an address in the default address space. It is required to be able to specify the address space of the register value. - There is really limited support for bit offsets of location description. This issue was already found by others who worked on packed array support for ADA language. The array could be packed in such a way that their start is not byte alligned. There is no way to describe this in DWARF, so gdb implementation in required for the packed array to be copied to the byte alligned addresses and then passed that buffer in the expression evaluator. This approach is restrictive for more complex scenarios. All these restriction are caused by the fact that DWARF stack can only hold values which size is not bigger then the size of the DWARF generic type. This means that intermediate result of any DWARF operation needs to fit in such a small representation. DWARF Version 5 does not allow location descriptions to be entries on the DWARF stack. They can only be the final result of the evaluation of a DWARF expression. However, by allowing a location description to be a first-class entry on the DWARF stack it becomes possible to compose expressions containing both values and location descriptions naturally. It allows objects to be located in any kind of memory address space, in registers, be implicit values, be undefined, or a composite of any of these. This approach unifies the location description operations with general operations. This in turn allows addition of new DWARF operations which can push a memory location description with any offset and in any kind of memory address space. The number of registers and the cost of memory operations is much higher for some architectures than a typical CPU. The compiler attempts to optimize whole variables and arrays into registers. Currently DWARF only allows DW_OP_push_object_address and related operations to work with a global memory location. With this change, push object address mechanism can be modified to work with any location description. This would also removed the need for the passed in buffer mechanism that ADA and GO languages currently use. The proposed implementation in this patch series is completely backward compatible with the DWARF 5 standard. Although the patch series is designed as a whole, the first 23 patches could be viewed as a standalone subset that introduces the idea of allowing location descriptions on the DWARF expression stack, while last 5 take advantage of that functionality to implement new set of DWARF operation which would not be possible without it. Zoran Zaric (28): Add new register access interface to expr.c Add new memory access interface to expr.c Add new classes that model DWARF stack element Add to_location method to dwarf_value class Add to_value method to dwarf_location class Add read method to location description classes Add write method to location description classes Add deref method to location description classes Add read_from_gdb_value method to dwarf_location Add write_to_gdb_value method to dwarf_location Add is_implicit_ptr_at method to dwarf_location Add indirect_implicit_ptr to dwarf_location class Add is_optimized_out to dwarf_location class Add new computed struct value callback interface Add to_gdb_value method to DWARF entry class Change DWARF stack to use new dwarf_entry classes Remove old computed struct value callbacks Comments cleanup between expr.h and expr.c Remove dwarf_expr_context from expr.h interface Move read_addr_from_reg function to frame.c Add frame info check to DW_OP_reg operations Remove DWARF expression composition check Add support for any location description in CFI Add DWARF operations for byte and bit offset Add support for DW_OP_LLVM_undefined operation Add support for nested composite locations Add DW_OP_LLVM_extend DWARF operation Add DW_OP_LLVM_select_bit_piece DWARF operation gdb/ada-lang.c | 2 +- gdb/compile/compile-loc2c.c | 16 + gdb/dwarf2/expr.c | 4252 ++++++++++++----- gdb/dwarf2/expr.h | 272 +- gdb/dwarf2/frame.c | 74 +- gdb/dwarf2/loc.c | 57 +- gdb/f-lang.c | 6 +- gdb/findvar.c | 4 +- gdb/frame.c | 45 +- gdb/testsuite/gdb.dwarf2/dw2-llvm-extend.exp | 147 + gdb/testsuite/gdb.dwarf2/dw2-llvm-offset.exp | 328 ++ .../gdb.dwarf2/dw2-llvm-piece-end.exp | 191 + .../gdb.dwarf2/dw2-llvm-select-bit-piece.exp | 138 + .../gdb.dwarf2/dw2-llvm-undefined.exp | 144 + gdb/testsuite/gdb.dwarf2/dw2-op-call.exp | 2 +- gdb/testsuite/gdb.dwarf2/dw2-param-error.exp | 2 +- .../gdb.dwarf2/dw2-stack-boundary.exp | 2 +- gdb/testsuite/lib/dwarf.exp | 14 + gdb/valops.c | 131 +- gdb/value.c | 70 +- gdb/value.h | 4 +- gdbsupport/common-utils.h | 18 + include/dwarf2.def | 8 + 23 files changed, 4425 insertions(+), 1502 deletions(-) create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-llvm-extend.exp create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-llvm-offset.exp create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-llvm-piece-end.exp create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-llvm-select-bit-piece.exp create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-llvm-undefined.exp -- 2.17.1