From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 0442F3858020 for ; Mon, 19 Oct 2020 02:08:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0442F3858020 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.11] (173-246-6-90.qc.cable.ebox.net [173.246.6.90]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 66D971E58E; Sun, 18 Oct 2020 22:08:10 -0400 (EDT) Subject: Re: [PATCH] gdb: add support for handling core dumps on arm-none-eabi To: Fredrik Hederstierna , gdb-patches@sourceware.org, Paul Mathieu , Luis Machado References: From: Simon Marchi Message-ID: <688f8081-e972-2ca1-255a-14b63e9e173d@simark.ca> Date: Sun, 18 Oct 2020 22:08:10 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Mon, 19 Oct 2020 02:08:12 -0000 On 2020-10-16 8:02 p.m., Fredrik Hederstierna via Gdb-patches wrote: > Hi > > I saw that recently there was new interest of corefile support for arm-none-eabi. For others, Fredrik is referring to this other thread with the same subject: https://sourceware.org/pipermail/gdb-patches/2020-October/172258.html In this other thread, we deviated from the main subject trying to figure out how GDB can differentiate a Linux executable from a bare-metal executable. Maybe we can just ignore that for the moment and get something simple but useful merged. This problem won't occur if someone is using a toolchain built with --target=arm-none-eabi. And if GDB is built with support for the Linux osabi, then the user will just need to do "set osabi none" to override it. It seems to me like it's better to have that than no core support at all for arm-none-eabi. > In the past I have tried to raise interest of this several times, but with limited success unfortunately, > so I am happy that possible there could be an opening to get this support into GDB, > and I would like to take to opportunity to also try push some more for GDB maintainers to try get support for this very useful feature. Indeed, it's apparently something that comes up often, I'm all for it. Let's try to get it to work this time :). > I already tried to push in the past for my own patch that also support eg floating-point support, and gcore etc. > The patch is using linux core file format as starting point but has stripped out Linux specific parts. > > See > https://sourceware.org/bugzilla/show_bug.cgi?id=14383 > > The GDB verision at the time was GDB-7.11.1 so it may be out-of-date. > (The post in mail-thread: https://sourceware.org/pipermail/gdb/2014-September/044559.html) I skimmed your patch, and I see that you implemented the support for "generate-core-file", which is awesome. It's one of the comments I had on Paul's patch. > If there is interest of adding this feature now, I could also try help to get this feature into GDB. > > I also believe that there is some need to 'formalize' the format, and my best idea so far is to try adding corefile to some popular 'bare metal' target RTOS. > I've been thinking of defining a format for FreeRTOS, but basically being a bare-metal target. I think it would make sense first to make GDB able to generate cores (with generate-core-file) and consume them. It makes it much easier to test than if we have to rely on an external tool (plus, it's useful). In theory, it should be able to generate a core while connected to the GDB sim target, which means that everyone can do it, no special hardware or tool required. Once this is done, it should be easy to go to projects like FreeRTOS and suggest adding things like that. > The idea then is to have some PC host supporting tool to convert/generate corefiles from some custom memory dump formats. > The FreeRTOS (or any other bare-metal alike OS) could maintain this supporting tool. Indeed. One question for you: when making GDB generate the core, I presume it would always have a single thread, as when debugging a bare-metal ARM processor with GDB, you see a single thread. Assuming you make that tool to convert a memory dump of a FreeRTOS system to a core GDB can read, would you make each FreeRTOS task appear as a separate thread in the core? > Here is one example what I investigated, a similar PC host conversion app that could possibly be basis of such tool, example: > https://github.com/rogercollins/bare_core > > I think next step is to define/decide a format that would be accepted by GDB maintainers, eg FreeRTOS-bare-metal or something, > then work in parallel with some supporting host PC tool, but maybe this should not be part of GDB itself? > Any comments or ideas are most welcome! As I said, I think the first logical step is to make GDB able to generate cores and consume them. The "Linux format minus the Linux-specific parts" format sounds good to me, but you would need to specify what are those Linux-specific parts that you removed, for clarity. Can you and Paul maybe sync up (and with Luis as well, probably) on what are the next steps? I think your patch was a great start, but it would need to be rebased. You could also look at Paul's patch to see if there's anything you'd like to pick from it. I'll be happy to give it a try with my NorthSec conference badge [1]. It runs a Cortex-M0 that we can debug using a Black Magic probe [2], so I think it's a good real-life example. Plus, I made it run FreeRTOS, so it would be a good candidate for that too. Simon [1] https://montrehack.ca/images/19-09_nsec_badge.jpg [2] https://github.com/blacksphere/blackmagic/wiki