From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id AP3kDrgp4mOpLCwAWB0awg (envelope-from ) for ; Tue, 07 Feb 2023 05:36:40 -0500 Received: by simark.ca (Postfix, from userid 112) id 381391E15D; Tue, 7 Feb 2023 05:36:40 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=XAR4BJD4; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.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 2D7A51E0D3 for ; Tue, 7 Feb 2023 05:36:39 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1B2493858D33 for ; Tue, 7 Feb 2023 10:36:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1B2493858D33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1675766196; bh=064rKrFpW//Qe+Dz2QwYEA3L2LceP3/3DRYWawU9VFE=; h=Date:To:References:Cc:Subject:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=XAR4BJD4IcUYictll48GpPq5cGKrVHzJEV9LIxOIZU9m78WNgY5DMSDYeYJ6KLnCC GRWwA9xV3X99c2fSS6PfwQUdSYi9rn730dChVnKrrO6HFI6m/GC6K7j+A0ODc+VSIh ypK5U04QE4HL5ul/iYw0T/fL45N5+Pc2Na25cLbE= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 162DC3858D35 for ; Tue, 7 Feb 2023 10:36:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 162DC3858D35 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pPLKX-0008CK-SN; Tue, 07 Feb 2023 05:36:05 -0500 Received: from ip5f5a8893.dynamic.kabel-deutschland.de ([95.90.136.147] helo=[192.168.111.41]) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pPLKT-0001hS-Cq; Tue, 07 Feb 2023 05:36:05 -0500 Message-ID: <299ca968-412e-5e43-32d6-f0d136cec7bb@gnu.org> Date: Tue, 7 Feb 2023 11:35:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Content-Language: en-US To: Christian Biesinger References: <87eba601-e753-02ac-0645-45c09377cac6@palves.net> Cc: Pedro Alves , gdb@sourceware.org Subject: Re: Is corefile support for missing on Win32? In-Reply-To: <87eba601-e753-02ac-0645-45c09377cac6@palves.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Sobisch via Gdb Reply-To: Simon Sobisch Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" This is especially a call to Christian Biesinger to ask if there was any more work on "supporting minidump with GDB"; but there's more content "inline" in the text, too. Am 09.06.2022 um 18:20 schrieb Pedro Alves: > On 2022-06-07 20:30, Simon Sobisch via Gdb wrote: >> Testing with MSYS2 generated mingw64 gcc 12.1 + gdb 12.1 resulted in "everything working" ...until I needed to create a core file. >> >> (gdb) show arch >> The target architecture is set to "auto" (currently "i386:x86-64"). >> (gdb) gcore test.core >> warning: cannot close "test.core": invalid operation >> Can't create a corefile >> >> (with gnutarget auto, pei-x86-64 and pe-x86-64) >> >> I see that the first error message comes from >>   gdb/gdb_bfd.c (gdb_bfd_close_warning) >> and the second from the default implementation >>   gdb/exec.c (make_corefile_notes) >> >> >> This issue seems to exists for longer as some SO question [1] asked about this over 5 years ago. >> >> Further testing showed the same issue with same tools in MinGW x86 and with "good old MinGW" using GDB 7.6.1 / GCC 9.2. >> >> Testing with cygwin-x64 (GDB 11.2) shows the same result. >> > > Native Windows GDB was never able to generate cores. Basically because cores are ELF objects, > while Windows is PE, so it's kind of a foreign thing. I see. That's a real pitty, but maybe this improves some day. > However, Cygwin comes with a separate utility that is able to dump cores in ELF format, and > Windows GDB is actually able to read those. This utility is called "dumper". See here: > > https://www.cygwin.com/cygwin-ug-net/dumper.html > > Sources are here: > > https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/utils/dumper.cc > > If someone wanted to work on it, I don't see any obstacle to GDB's gcore command > itself generating an ELF core in the exact same format. That would be an interesting point I'll check with its contributors later. In the meantime I did test the dumper on cygwin, it works there but only in specific cases (I did not get it to work in mot cases "while the process runs", as it often generates a file that contains only threads in the Windows API where no debugging symbols are available and therefore all threads have broken backtraces with not a single one in the program space one is interested in. This _may_ worked around if the generation could be postponed until the code reaches "program space", but I don't know enough about that (and it won't work on a "real abort". Note: the part where it _did_ work was when "dumper" is hooked into cygwin's internal abort handling, then reaching a SIGSEGV. The corefile was not usable when, for example, the user code did `raise(6)`. >> I guess the system's minidump format cannot be processed with GDB, can it? > > Unfortunately not. Christian Biesinger did write a patch to add support for it while ago, though: > > https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/cbiesinger/minidump > > AFAIK, this was never finished/contributed for proper inclusion, and I don't know how far > that is to being complete. We'll see if/how Christian (or others that now about that approach from 2020) answers. Thanks for any hints, Simon