From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id daLVGLI+FGD2JQAAWB0awg (envelope-from ) for ; Fri, 29 Jan 2021 11:58:26 -0500 Received: by simark.ca (Postfix, from userid 112) id 52F811EF80; Fri, 29 Jan 2021 11:58:26 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,MSGID_FROM_MTA_HEADER,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id D7E851E945 for ; Fri, 29 Jan 2021 11:58:24 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 586F93938C39; Fri, 29 Jan 2021 16:58:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 586F93938C39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1611939504; bh=t1piCHjHT/Tj1W9+oN/U9h/+0XpAUzGpsy1qBabc3Ig=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=yHpgujZDbe7b5OOrUJ6wgdTGiiF4DYLRDLCpcDEUximnpX4c8ojutAx2FyghH6g6+ tHCMTCMvlqoddrGNDvtZ8Nv8/jP85uiO8dIQoH/ZsUYZzPJPeZvTWLjN74MbRzme8z kQ4RE2LD0x/20xo3OuJHKoG3exdqbgbdjGFZG3HY= Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2063.outbound.protection.outlook.com [40.107.244.63]) by sourceware.org (Postfix) with ESMTPS id A065C38708A6 for ; Fri, 29 Jan 2021 16:58:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A065C38708A6 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dR3qX2rwC8gpVamcC73jKdrhni6sTr4xzdcfsbDHezZziFew+WlnoRAhpzKVia5hPH5czuJw+awUE0wy5VPvAsc/rVDgCdkIdltFQkqO3qCQzIxaXfJdJu1ymY/x42H7FZjSkFRywDRHcQoYhbvNU+GelVcIViRdK5fbBZxgKU3fjna9HyErunwU0D8sLWiRhmynX4NhcrlTS5ASkmYEfXVi5hEfmVZ9MfgUsBz81vqO3DR90n4TlLaznMh/2niRVQE+H1c+PxTqwDoZmmydP6h77wdVizUsnm9vzBZHrIp2UQNC9MAxDNaVwXW/FvkgQ0cDasJaWVLJ06sgcdIh5g== 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-SenderADCheck; bh=t1piCHjHT/Tj1W9+oN/U9h/+0XpAUzGpsy1qBabc3Ig=; b=CwYBxu7Plch3Kt0CMJRgQiild9jPxE5SsQdN/HKCMQ/+3E/yiILAXjIHrERIMLkPBPbNxnNgyYkTkuC6emZfSNlWsQ3L4jE8hx2WHHTp7jlnoCUoVeP5ufVvlpOtKOaFjUeupoccoBnH7yD+oleLkMM5js7I7wenNfF7P/0NWr34gu2JrahJWTzIkKJbX6SH7mntt5h6JFVrLH1hxmST+68SzBYueWmY/p4YtrdUddec9uqR8xRcZb4JxR72bCOXA7OuhN5mTk++nWF020tCZq7BhDf/mpCQ72NpOjBxBp26ub2IdrkoeNAN1xJYhL+4SGGiWgSd9ZyuXZtN9b55Yw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none Received: from DM6PR12MB2762.namprd12.prod.outlook.com (2603:10b6:5:45::15) by DM5PR12MB1369.namprd12.prod.outlook.com (2603:10b6:3:6f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.19; Fri, 29 Jan 2021 16:58:16 +0000 Received: from DM6PR12MB2762.namprd12.prod.outlook.com ([fe80::31d8:f503:f7b2:f44]) by DM6PR12MB2762.namprd12.prod.outlook.com ([fe80::31d8:f503:f7b2:f44%3]) with mapi id 15.20.3763.019; Fri, 29 Jan 2021 16:58:15 +0000 Subject: Re: [PATCH 10/13] gdb/testsuite: add .debug_loclists tests To: Simon Marchi , gdb-patches@sourceware.org References: <20210120053925.142862-1-simon.marchi@polymtl.ca> <20210120053925.142862-11-simon.marchi@polymtl.ca> <6fe96ff5-3f11-585c-0331-62d1fe234bd2@amd.com> <56f87bf1-a43a-a710-005a-502101412d35@polymtl.ca> <491bdd1e-4ea5-eefc-0cc9-173e1fd8efc0@amd.com> Message-ID: Date: Fri, 29 Jan 2021 16:58:10 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [2a00:23c7:5a85:6801:cf:c92a:a445:6f68] X-ClientProxiedBy: AM3PR07CA0070.eurprd07.prod.outlook.com (2603:10a6:207:4::28) To DM6PR12MB2762.namprd12.prod.outlook.com (2603:10b6:5:45::15) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [IPv6:2a00:23c7:5a85:6801:cf:c92a:a445:6f68] (2a00:23c7:5a85:6801:cf:c92a:a445:6f68) by AM3PR07CA0070.eurprd07.prod.outlook.com (2603:10a6:207:4::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.8 via Frontend Transport; Fri, 29 Jan 2021 16:58:14 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: d8e7daae-de6e-478f-d530-08d8c477119a X-MS-TrafficTypeDiagnostic: DM5PR12MB1369: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: SdNl7Y0KpEQI/vAB8YzyOAmwtk9H1KUEhI251k6g603vkMToYSW9Aj9tLj7ZS8lxk4GoFJb1QGgcHOGH8V/E2E9FrZhOeQ4hkwo/x57fw4bs/HoqPsrycz0ocp9ao++q3QYK9vcsFow3qDQhIV+vqBMicFLL45w8TNKYEeoKbjyVETMy3OpC4SuNSgJZrbCiP6N2bc2zm4TdStyZOJ1z08SzEJrCIEive8FYjl84MpAI56K72HUpjzp5FLqPnoQ+fTeG1D28SYUECwY5n1au1h+YvJnvrwuZ8YMPHQ9EaF7K3Dl03hhSoJE/gAxeO8uDbkHPw2ayYL5MG7qbyIWb2MrqhwxOQSd0xwfWQG37pFsUQF0ruMgJA+f9dBb5Ur+p3Lb0MJyoaki48BfQ1XxkXF4Ekv8TCaxiQDMW+WivoYmD6tMA3UhD80puiPLnS5sfWSRPMt3tuZyhy6yy218QdiR2voZxu5F4SENBVn7u5F7A3vcs975eE1qDReTKATQmAU6Ig9sNBlFQJ5psTod1kgZXXb1F+kscWU4uAWQNnzPR0J0M3B6WzyzbBCKGdQKSQsHEdyxroDTiFNz4HkX1uIZHU94ujxxsfs4U89flxlXUyfDS0hynPV5pw4wbaEmthM6jLior9ok8oYKUWoGH0MqZhf5sTWou7y4dGXVtI+r2z3grl2OSOmzUaaPf5ka1YrpHTyCrco8nMPMPeuDgMg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR12MB2762.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(366004)(376002)(346002)(396003)(4326008)(66476007)(66556008)(316002)(5660300002)(2616005)(31696002)(966005)(66946007)(6486002)(186003)(45080400002)(31686004)(6666004)(2906002)(86362001)(52116002)(8676002)(36756003)(478600001)(8936002)(16526019)(142923001)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?aUxkV3lMVGxSaVlnUUQzc1Bvd294OFI1VHM5OENYZ3g1dFN3VCtxbGN4MGtX?= =?utf-8?B?WnFzaGprL01DUlhxTVdZR3NmeW15aVFvMUFiYjBiVXdGMy9KVWdaNkw5QnpI?= =?utf-8?B?MDZlOXloOEN3SjZDRGxJMmJsejd1RHY3UlR5K0JIc1c3cDFrNlM2c3R0cmpw?= =?utf-8?B?NkVzbGt3Qm8xSE9jd20yRHVvY2NMZkZoMzlmUG50UnZGS0J5TFRmRUZrQ1hN?= =?utf-8?B?ZUdkSkpqVDdFM25GTHNkNnlOMzRuQmZDVU5FZFkwaFp1eE9NaENpMjIweVd1?= =?utf-8?B?emVZRVBUMXJWb1NSUTMzZjVLenBlRWRmeVFjS0paSytXOGFCSHRaS2EweU9P?= =?utf-8?B?WkkraHBveDJpaWdVcVZIOHBDMmxSQ2FCUHpEMmYzeXlZYjF0dDlQSVJHN01O?= =?utf-8?B?KzVYcXh3amduK21ab2RkN0dzbmhZQVZ6NkY0VzdvNlNoM2FGYWhJZXljalFP?= =?utf-8?B?RDZtSFVaQUZBQmVwMWNONUIxUDRPUWYvc3dMRFd5cS9HQThQY3V0OHpxWEVT?= =?utf-8?B?akZTRUp0cUNHUEJCRndWY2k1Q214QVY3NHpuNWM4OXA4OFpoSVBSczdZWHRn?= =?utf-8?B?MG12dW94NlE3OEs0QVYxSDBBQ2tzdTFuM2tVeXc0TTBCVVhKSnRVRGZLbnVs?= =?utf-8?B?d2pLTHNaNmFDa2ROSFhEWXdLTm5vcCtzUG5EQmUzeFhJSVAvQ2tQMFV5UWJG?= =?utf-8?B?MFJNYjlqc1FKSnk3ejhHb0pzTWorQWJiOEhkdnZ2Qzc5MEpYUWlOQnNYYVph?= =?utf-8?B?MW00WTk5TjZlZFRjZnkzTXpscUYxdlJkTnJ4SVpENWZ2QWJtUHFXdE1oekhJ?= =?utf-8?B?UWYvc000Vmw5eWFIanFKdnViQXNTYjNqczMvK3oreElXUHp6NHVpcG5idXZm?= =?utf-8?B?QytUZW1WSWNVNERaV0JBNDVwQnR6U3VXNWlPWTdPMjJreGF1WHNqYWlVZzY1?= =?utf-8?B?TWJybnBvUk5oZzRkbXRmWkVKbFRRM1dsU1EzdUVGcUQxVlZEWVFxdndTbloz?= =?utf-8?B?N2VEYjM2L2ZSVU9XQm96bVN6QVFWYnVpODYyUHJpdlFPR1NHTlE4MlptQUFq?= =?utf-8?B?TnJaYTVWd3pkMlpwbjM3Y1BTSW9keExZZ3R5eXltOGgrUXNOSndmNXhIcmRz?= =?utf-8?B?VHdBRjA3Z01kMW80UkdZclEvQVBzcW5pM1h4d2NVWnY2TkJJQXhldWd4aUhN?= =?utf-8?B?NEhLRU5pRE1ZVXRzd1FUOU9wWk03N0h1OVkzcW00MVA2N2s3aEN6dTFKWk1p?= =?utf-8?B?dHROdVlCVXI5RTBKSkZIMjk4a2pmSHFmRXpBZHFsNHpuTlhTM0ZNSnNtQTFt?= =?utf-8?B?U241M3lHTGVWU24yalZoWEZub2tZMDBkek5IbjhXT2MvZW8vSjB0dVFzSzNK?= =?utf-8?B?UGVtYUlOS0svd2hPMlFLM2N4UDlrYmRaSjNPOWdldmpON0djYU5ialNISmxN?= =?utf-8?B?V1pFNWNCV3ZMV1FxcmFkemtYc2lLNW1JdWJ0Qlh4VzVkMCtNVHBweFZaQ0FO?= =?utf-8?Q?FZ2zrgNHhou2FfuUuTPnbptlb1f?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: d8e7daae-de6e-478f-d530-08d8c477119a X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB2762.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2021 16:58:15.8681 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: BMY4lJpuFaw8duvGnKM2hePm36pMk0/aXEt/hLh7IeWuOFC5clXnwt8g/FrhBWhuEygItWBOXfXQuCxdP/mKTQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1369 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: , From: Zoran Zaric via Gdb-patches Reply-To: Zoran Zaric Cc: Simon Marchi Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" >>>>> >>>>> Add tests for the various issues fixed in the previous patches. >>>>> >>>>> Add a new "loclists" procedure to the DWARF assembler, to allow >>>>> generating .debug_loclists sections. >>>>> >>>> >>>> Thank you for this contribution. >>>> >>>> Having a loclists support in DWARF assembler gives us so considerable testing flexibility and decouples the gdb testing even more from what compiler is expected to generate. >>>> >>>> The only thing missing now (at least in my mind) is the CFI support but that is a big project for the future. >>> >>> Given that: >>> >>> - the actual assembler (GNU as or other) already has support for >>> specifying and generating CFI, and >>> - a test case that wants to use specific CFI would contain some >>> assembly code already, to control exactly which instructions are >>> generated >> >> This is not exactly true, you can always define a CFI that doesn't need any assembly code considering that register values can be set from the the test itself or if only CFI register rules that target a memory locations are used. > > Isn't a CFI table essentially a big mapping that says: > > - At address X + 0, here's how you'll find the saved registers > - At address X + 2, here's how you'll find the saved registers > - ... and so on > > So ultimately you want in your test case to know exactly which > instructions are generated, and their addresses, to generate the CFI > table, don't you? And for that, won't you write assembly? You can still write a CFI information that covers the whole function without going into details on a per instruction basis. In the same way how you can write a single location description for a variable right now without thinking if that variable exist in the actual code or is it mapped to only one location. If someone wants to do it per instruction basis later, more power to them. It is true that one really needs to know what they are doing but that is no different to the current symbolic information support. > > I'm not sure I know what "CFI register rules that target a memory > location" means. A register from a previous frame that is currently > saved in memory? I don't really understand what that changes. My point was that in that case you can still write a fairly complex CFI information that never touches ABI sensitive resources like a specific register. This will get even more useful with future addition of address spaces, where pieces of a register might be spilled to different kinds of memory like AMD has in the case of their large vector registers. > >> With the new extensions that I've contributed (and are currently under the review) the register rules mechanism now supports any location description to be part of the DWARF expression. With this extension, you can imagine that a very complex DWARF expression that doesn't use any potentially ABI sensitive resource, can still be written and tested in the same way as any variable location. > > Hmm but in the end it's still just a sequence of opcodes, isn't it? Same goes for variable location descriptions right? And we still support those in the DWARF assembler. I have written full debug information in assembly in the past, and apart from encoding the DIE relationship by hand, I didn't really see that much difference between encoding variable location to a CFI entries. Both equally unpleasant. >> Another option is to only hand write a CFI table for the top level function (frame 0) and design a way to merge the original CFI generated by the compiler for other functions with the hand written one. > > I don't remember how exactly things are merged by the linker, but I > suppose that would work. But again, you'd probably want to write that > top-level frame 0 function in assembly - I think. Or if don't need to > write different rules for different instructions in the function, I > guess that function could be written in C, and you make CFI rules for > the whole function's range. But you'd need a way to tell the compiler > to not generate CFI for that particular function. This function could be an empty function with a single asm statement that could be compiled separately (with the instructions to the compiler to not generate debug info for it). We don't do that right now but it doesn't sound like a deal breaker. > >> >> Also, with a potential new operation DW_OP_LLVM_call_frame_entry_reg described at length here: >> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fllvm.org%2Fdocs%2FAMDGPUDwarfExtensionsForHeterogeneousDebugging.html&data=04%7C01%7CZoran.Zaric%40amd.com%7C20c7017e3b7f47e5f39808d8c46e9356%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637475326499683800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ww3TjCpYOjj7FtUuTSr93VqHEErO1LoLJFRJGK3hhFg%3D&reserved=0 >> >> This would allow us to test any CFI expression of the frame we are currently stopped in. >> >>> >>> I don't think our assembler needs to know how to generate CFI, you'd >>> just write it in platform-specific assembly. >>> >> >> But, isn't this the case for any part of the DWARF assembler functionality? >> >> Writing any complex DWARF expression fast in any assembly is hard and time consuming. > > No, you can't express symbolically any DWARF expression at the assembly > level. For example, you can't describe the tree of DWARF DIEs using > directives in assembly. All you can do is output the raw bytes using > the .byte and friends directives, but that wouldn't be humanly feasible. > So instead we have this higher level language (our DWARF assembler) > where we describe the tree of DIEs and have it output the .byte > directives for us. This all depends of ones view of what is convenient and what is not. From this discussion it sounds like the DIE relationship was the main motivation for developing the DWARF assembler. I always though that it was for general convenience of writing debug information in one test. While I agree that writing DIE relationships in a raw byte format is daunting, so is writing a really complex DWARF expression. This will get even more daunting when lane masking, address spaces and large vector registers come into play. I have seen DWARF expression with over 15 operations and those are not fun to write in a byte format. And why not give the ability to mix and match symbolic variable information over a frame change with hand written CFI rules in one test? > >> >> I agree that adding a CFI support requires more thought and effort and better understanding about how the CFI works and what is safe to use from a test writer perspective, but I can definitely see the benefit of adding that support in the future. > > In the event we want to test a CFI construct that isn't yet supported by > the assembler, then it could make sense to write own assembler that > emits the right bytes directly. I agree that what we have is good enough right now, but I wouldn't want us to dismiss the idea completely. I might be tempted to implement it in the future :) Zoran