From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) by sourceware.org (Postfix) with ESMTPS id 7D87C385E038 for ; Thu, 9 Jun 2022 16:20:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7D87C385E038 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f53.google.com with SMTP id n185so12677664wmn.4 for ; Thu, 09 Jun 2022 09:20:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=zTi0S38WfAJJ6HeKZTMAE4rFquWpiAyYa6SkyUwAl74=; b=JKV6HXtuWAbC6Tg6tLrXwy8PHmzyTrCkAwrAFHvUkUlAS6ndLvlIgzUNjzyYQxUGig pOSoVvJpeUtAm0nWgKfg+q/VRlIv2dZDHF3ZT/UdaOwBB2Ifsk22JEfsuShwyNVN++G9 NybF35TrV7tB392YyXGQVLEd8BCQylNfM8n0yrMNLOg1ZxQ7Av02Uak37Jcd71dVxro2 +OAiqXMv0rYucTZbZuhzn+xQq6yPKCDphZj7WbPZbSlHu9C0XgA4ixjT/o88eubp3GdK S9p66+XEIHJtHNx6xG/jh5ALHkjRjT5ItcU6w31TIk6x1AvY0jDrvzDGyaIV1NM6/U6w clsw== X-Gm-Message-State: AOAM5310zHSFikoY/sUgdIcI017K8FaM16nz7PpLF5exaVqw11ceBRam f4G3i+kJV29a+CT55m/sTch+x+JxVLNFkw== X-Google-Smtp-Source: ABdhPJxPitQzvjYMMjpcGWm6nmuwlqXfJwvOKP+qIXyZxFnd0fX9ZB4rxfVKXdGCLewQfl+kM572xw== X-Received: by 2002:a05:600c:3848:b0:397:51dc:9385 with SMTP id s8-20020a05600c384800b0039751dc9385mr4103416wmr.65.1654791646297; Thu, 09 Jun 2022 09:20:46 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id y16-20020a05600c365000b0039c5328ad92sm12145540wmq.41.2022.06.09.09.20.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jun 2022 09:20:45 -0700 (PDT) Message-ID: <87eba601-e753-02ac-0645-45c09377cac6@palves.net> Date: Thu, 9 Jun 2022 17:20:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: Is corefile support for missing on Win32? Content-Language: en-US To: Simon Sobisch , Simon Sobisch via Gdb References: From: Pedro Alves In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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@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: , X-List-Received-Date: Thu, 09 Jun 2022 16:20:49 -0000 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. 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. > 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.