From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Ke3SCFaL52mRZDAAWB0awg (envelope-from ) for ; Tue, 21 Apr 2026 10:36:06 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=MshULCJU; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 20F151E067; Tue, 21 Apr 2026 10:36:06 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A53201E067 for ; Tue, 21 Apr 2026 10:36:05 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 26E7F4BA902E for ; Tue, 21 Apr 2026 14:36:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 26E7F4BA902E Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=MshULCJU Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 4417D4BA23CA for ; Tue, 21 Apr 2026 14:35:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4417D4BA23CA Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4417D4BA23CA Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776782137; cv=none; b=je5SQeKqNdUzb8tDctrtyT0MGBggIc1YsuwfeEQbyApFBXOlHClOvuIcZlzOGAagb300oe0zRHoQJVixujpXYUmaaKSFSNCYjo0dE2QkHUuNgglhwI3G23D5z1GUNAK1qddwAYlrM0jbIjiEN4xQbh5S38nXP0Dr+pwMVYsi2oY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776782137; c=relaxed/simple; bh=aF4y23JDwgip0GqzXG45omxilr5W5tK2w/NkxYG870Q=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=ocayC+MA9yAKZsyKaG5fHd6gLRGGhiSrVYJlg+Z3v9h0CwIggMEFm/KZfLtDI3kIgxuxTxDjawX56ZHhalvxoNAJI5ZnkTDx7aiOySi8GO44wusTROn80QM5qXOfIb/kTwb7UcYn5ntisnSTdlw36G8+jJAVQg1eWo8/XMsfr7M= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4417D4BA23CA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776782136; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Cu7GAOz/I0Lp4NbXgUcppsM9xez+Y42vFoAgFZdm6uY=; b=MshULCJUqRNZ2SkRomclSZ3J4w9VgR6cp7hmVWlU7QoXq2pTmQVDsPLktN/tKb5WOn+Z9K H6gSRt2AMUIe6dxdGHq3kMWxZ1F8Ms2rMBzfRjk5jVxSue+PqNE8Pcsr083XZ4eCz7JcGw +lvziZ2sm8v38EDanshFSxLQZOUH5oE= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-164-6GTJfOA5NY2niDt5QM00Ww-1; Tue, 21 Apr 2026 10:35:34 -0400 X-MC-Unique: 6GTJfOA5NY2niDt5QM00Ww-1 X-Mimecast-MFC-AGG-ID: 6GTJfOA5NY2niDt5QM00Ww_1776782133 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-43d03065782so2987366f8f.0 for ; Tue, 21 Apr 2026 07:35:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776782132; x=1777386932; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Cu7GAOz/I0Lp4NbXgUcppsM9xez+Y42vFoAgFZdm6uY=; b=l7Yt8jgH6ikeI95s6veMZya9WJBdCMI5EIrj65xcClpP1o4eAvU+cUoADP8ICGnjvy V9zCUYfPXQ7CI1mof2zX872ZVBJTEY8s6wzzTtFCnXLRue0ebZO+NYzPjCz46Cn1pgIH hW9TygKSpRbEjshaNUGe8i9CGybxANg6Vf2f0SmNVMNzh7J992ow0iphqPPq1dRBF7ce mKguG4URPgFgpugvhilG6O9nhbEtoJgYA27WDhoBaMdHJTx0uK/vRMlnnmz9N2nPswqR 2AmS42qGEmQ863+7ZWEDPIAD0Wc58UNACPrw5pCp7u9gMCwWxzDtA5aI6gtHfBLlp6pf +e7A== X-Gm-Message-State: AOJu0YyKWpXpngT/R9fmtC4kRL08D7OVrzXJy38OK61fpGH8DlwPGrNN OA7QM1h0pWJsyaFO2Y0j7zt4obIrtDqPTsJYVpnueU7lpWfxKVitHnktUJl+UkkxptwIcsVz1Br FXsnu63ROJJ8BbUNzMt+SWtxrBD+fycgGivUG6JLtMQFfssZN08WHHT7lXbQG/6KGYFgXVEZdGY B7CYKt7P5YeOCQ/HpW/NJvi7nkmQ068FNbfE1Le26ddzfKgNI= X-Gm-Gg: AeBDieuJIt0Na9W3xMLBidcF0gGIBg/deiyt8xKUhrNWy+bwuzAiA6DWVuXjVo5xHP8 4duMach/elOb8DM+fkwtEuLoh+Ba+wxhP6xQVHJ7ll76fZy1cPZDGxEC3zVzXA9rm2d1M8sGF2C EHqUJJVHFpZwMSyafZFdY//NhZ09bPmhXRCULve5TfnhYiKbguV4dZzF88wcpgkmWJbPMtX1MJ+ egDLgygIgBvJ1Wk2Lblv1bwSh5VdXnHHGqRS8PXsp/Fw4I0lw2IWiOuTFYZQxCazrnajDdWYZGk 94RecM/NaSteZNW/5tfIcu24J9qhB0kKMeXRcMAzyeIt/frb+gRkA67J1cknGsYRg+DFl5pzimL uU079AYOa8Oe4h+dBwBFAtekvXR4= X-Received: by 2002:a05:6000:2282:b0:43d:184:8aa2 with SMTP id ffacd0b85a97d-43fe3dc581cmr27301132f8f.16.1776782132361; Tue, 21 Apr 2026 07:35:32 -0700 (PDT) X-Received: by 2002:a05:6000:2282:b0:43d:184:8aa2 with SMTP id ffacd0b85a97d-43fe3dc581cmr27301049f8f.16.1776782131612; Tue, 21 Apr 2026 07:35:31 -0700 (PDT) Received: from localhost ([31.111.84.232]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43fe4e591cesm50519101f8f.36.2026.04.21.07.35.29 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Apr 2026 07:35:29 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Subject: Re: [PATCH] gdb/dap: add support for opening core files In-Reply-To: References: Date: Tue, 21 Apr 2026 15:35:27 +0100 Message-ID: <87a4uw2xg0.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 7bqZFhqoFFrnE2N5skOzR23Lsk1KTgjvrmd7Xg6j_Sw_1776782133 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Andrew Burgess writes: > This patch adds core file support to GDB's DAP interface. > > Core files are supported as a GDB specific argument to 'attach', the > new argument is 'coreFile', the name of the core file to debug. > > I think handling core files via attach makes the most sense; attach is > for connecting to existing processes, but these targets are (usually) > stopped as soon as GDB attaches, and that's what a core file looks > like, a target that was running, but is now stopped. It just happens > that core file targets are special in that the target cannot be > resumed again, nor can the user modify the program state (e.g. write > to memory or registers). > > Prior to starting this work I took a look at what lldb does. The > documentation is not super clear, but this page seems to indicate that > lldb might also use the 'coreFile' argument to 'attach': > > https://lldb.llvm.org/use/lldbdap.html#configuration-settings-reference > > Like I said, it's not very clear, but search for "coreFile" and you'll > see it mentioned, just once, under the "attach" header. In order to > be compatible with lldb I used the same argument name with the same > capitalisation. > > The new argument is added to the documentation and mentioned in NEWS. > > I had to make some changes to testsuite/lib/dap-support.exp to support > this new feature. There's a new dap_corefile proc to handle setting > up the initial connection. This seemed cleaner that overloading > dap_attach, even though under the hood it is still an 'attach' request > that gets sent. > > The new test tries to write to memory and registers with the core file > target in place, neither of these requests succeed, which is what we > want, but the exceptions are logged into the dap log file. The > dap_shutdown proc calls dap_check_log_file to check the log for > exceptions, and these two exceptions are spotted and trigger a FAIL. > To avoid this I've added a new "expected_exception_count" argument > for dap_shutdown. Now we check that we see the expected number of > exceptions. We don't check for the specific exception types right > now, but as the test is already checking that the expected requests > fail, I think we're OK. I had a follow up thought relating to this patch -- I wonder if we should add a custom capability, something like: @capability("supportsGDBAttachWithCoreFile") then a DAP user will know if they can load a core file in this way or not. Obviously, this would need some doc changes too... I'm not sure if we have any custom capabilities yet, I couldn't see anything documented, so I guess not. Thanks, Andrew