From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id oGg1DfevjV/1SgAAWB0awg (envelope-from ) for ; Mon, 19 Oct 2020 11:25:43 -0400 Received: by simark.ca (Postfix, from userid 112) id 334E21EDF4; Mon, 19 Oct 2020 11:25:43 -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 CA7AF1E4B5 for ; Mon, 19 Oct 2020 11:25:42 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1A7603870890; Mon, 19 Oct 2020 15:25:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1A7603870890 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1603121142; bh=RZ5hg0albZqMoXioDnTHq5W/ENWANh+Ylb2vxKUxi+8=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=DaQ7+utMhINaCB4RKru7DaicoQvZBCH7s0h2nlA5BlAyfLhpOLscQImPP1KYctrUk GYnJP5BsjFbcHc2QdvrD6cdVA2qt7hfTydDEASD5pmYzen6JiEOhpUTrIwG4NT5ga0 jtr9jCyXkRT0oAodu01iT4JjT6E/ktQf48lx8kmY= Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) by sourceware.org (Postfix) with ESMTPS id D569F3857C4F for ; Mon, 19 Oct 2020 15:25:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D569F3857C4F Received: by mail-pf1-x442.google.com with SMTP id x13so133525pfa.9 for ; Mon, 19 Oct 2020 08:25:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RZ5hg0albZqMoXioDnTHq5W/ENWANh+Ylb2vxKUxi+8=; b=Gpv3F2OedwqMkg6f7qN2Bgi8WivhaEg0S+7tWXQDjw+jgM18Hami1iTn5YtjHLNP5C V4PdsZyxrQqESd8qOPql8w/6mhGnziZym0NyqbG6w0saMLXkxj89xBNP8b3iqMWM88Cc K7b3/QAkG4aoINYuEOn5ILosi9q2RQUR+O/akPJVfNjvjTjjMeQPle4Rw+t+5yklSjFa PsgPNUk75czB41sxMXQiUCVQya8Im8ROEmZbcQRJahooqtJbdloXhGHV2pyYZT/ea48f tZ7jLMyfisBOKakptOBQ+ZXhqEB4DgruO70G0C7UCiAo0o7S0VZsOxbtmw8RJxAZPrq1 95vg== X-Gm-Message-State: AOAM5336xWPNWziFsRiqoahQRrkv4UlLX2sFvLDDKvWej/ojLfcBpgtw UE2a8N38ENmx8Cmw0+t5FzrCQSLaJ/jfrV+LIyAu42/c2U4= X-Google-Smtp-Source: ABdhPJws+gP4bq8QYPxu3QSBE6bI2U+XxKIatB5V0yD2so3R7fB4D/07so/PQOrojU6nvVKFlWqgxHRyDNtdEIhXhA8= X-Received: by 2002:a62:92c8:0:b029:152:1703:2da9 with SMTP id o191-20020a6292c80000b029015217032da9mr114701pfd.60.1603121138665; Mon, 19 Oct 2020 08:25:38 -0700 (PDT) MIME-Version: 1.0 References: <688f8081-e972-2ca1-255a-14b63e9e173d@simark.ca> In-Reply-To: <688f8081-e972-2ca1-255a-14b63e9e173d@simark.ca> Date: Mon, 19 Oct 2020 08:25:27 -0700 Message-ID: Subject: Re: [PATCH] gdb: add support for handling core dumps on arm-none-eabi To: Simon Marchi Content-Type: text/plain; charset="UTF-8" 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: Paul Mathieu via Gdb-patches Reply-To: Paul Mathieu Cc: Fredrik Hederstierna , gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Hi Simon, thanks for keeping this moving! > > 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? I assumed that we could use .reg/xxx note sections to dump task information, haven't tested it though. That would be something that generate-core would not be able to do without support for the underlying OS. I imagine that we should be able to add some fort of support for FreeRTOS? My target runs RTX5, I'm not sure how widespread it is and if it is worth adding support for. That said, as long as the core format is specified and has support for multiple tasks (at least CPU regs), collecting that information and formatting it shouldn't be too much trouble on my end. > 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. Happy to. The patch that I proposed is quite minimal, the only nice thing about it is that it builds on top of master. Paul