From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 0M93MxqRjV95QwAAWB0awg (envelope-from ) for ; Mon, 19 Oct 2020 09:14:02 -0400 Received: by simark.ca (Postfix, from userid 112) id D0E5C1EDF4; Mon, 19 Oct 2020 09:14:02 -0400 (EDT) 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,URIBL_BLOCKED autolearn=unavailable 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 74D321E58C for ; Mon, 19 Oct 2020 09:14:02 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E4158386F81A; Mon, 19 Oct 2020 13:14:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E4158386F81A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1603113241; bh=m/oY1Q0f6irkwfX+5GLg29m+9QDzY5H1oMI2BNw1AMo=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=Aw5vq6YtQchlbzjJdWo7ZX9GBZNUZnTDkNBjHRCZg9lTv2BJnRozmhWyHKjhF4DrG WOWwSOJv6GFl7s7DHHqRD6eLi851L02IITpZXqUj3av7WHBWVlI8YN1xckA4RLy9ug JuwReqHzNRMIluZaKGM6bEOQ2xHXPxjv+xYR+5M0= Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) by sourceware.org (Postfix) with ESMTPS id 461853854826 for ; Mon, 19 Oct 2020 13:13:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 461853854826 Received: by mail-qt1-x844.google.com with SMTP id c15so6008923qtc.2 for ; Mon, 19 Oct 2020 06:13:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=m/oY1Q0f6irkwfX+5GLg29m+9QDzY5H1oMI2BNw1AMo=; b=lHzv8XZ6AYB0s5x6XavhXzkyzi+U2gmo3IhJTTVf5tj6Ac3hmnNm/YvRx8d1N44wvh 6j7YFe8ew0E9HrBZMo0BceU58PI8/JllkFt7/DgDV9WQ9YKrJXtDusG/p6j3WjtqJSTG T0uYxvsjYTpaqqHIdEDni482Xs8qXzG3S12vmilL6h/aGwtV1+AebQ2EninHmWkf0Gxm X4AI1PyjSq3meDey1P2GtDqww9j1RMpTH1cYvij+Y+ZyZXK4F4ojiJK8JWUVgS30M5hW 7q1tBgo5GnKHrSQyvALyDKtTdQ0U127dXky3cXuZmhVlyM3s0TKMsWoGg/qPa0PYboy0 GJMg== X-Gm-Message-State: AOAM532Rp355f8XbKSsLtfzBAIoRAIUKtWkZ8ICWRDeFq6qX+gn2XYws 3G+r0Ljiflob57bEkT/BLwOPQOzXNWQItg== X-Google-Smtp-Source: ABdhPJxwoliICI3r7OtJL2ypk+C57I/aLzgDRLLzwb55dESE5zRQ1BIui/gvzdFcsGEehVpGOcXWUQ== X-Received: by 2002:aed:35cf:: with SMTP id d15mr14842156qte.282.1603113238711; Mon, 19 Oct 2020 06:13:58 -0700 (PDT) Received: from ?IPv6:2804:7f0:8283:fe4b:38a0:82a3:b1fc:db00? ([2804:7f0:8283:fe4b:38a0:82a3:b1fc:db00]) by smtp.gmail.com with ESMTPSA id s17sm4078366qta.26.2020.10.19.06.13.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Oct 2020 06:13:57 -0700 (PDT) Subject: Re: [PATCH] gdb: add support for handling core dumps on arm-none-eabi To: Simon Marchi , Fredrik Hederstierna , gdb-patches@sourceware.org, Paul Mathieu References: <688f8081-e972-2ca1-255a-14b63e9e173d@simark.ca> Message-ID: Date: Mon, 19 Oct 2020 10:13:53 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <688f8081-e972-2ca1-255a-14b63e9e173d@simark.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Luis Machado via Gdb-patches Reply-To: Luis Machado Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Hi Simon, Fredrik, As was discussed in a private thread, it would be ideal for you (Fredrik) and Paul to sync things up and have a draft of a format that works for both, then we can go back to trying to fit it in GDB. I'm guessing we'll want to make it generic enough to accomodate other architectures etc, just like the Linux core file format. Alan and I can provide some feedback from ARM's side, and others can chime in for other architectures if needed. If you'd like to discuss the format itself, I guess the gdb@ mailing list would be the place to have a chat before we turn it into a proper patch. On 10/18/20 11:08 PM, Simon Marchi wrote: > 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 >