From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id q0EUNWxlzl8NSwAAWB0awg (envelope-from ) for ; Mon, 07 Dec 2020 12:25:00 -0500 Received: by simark.ca (Postfix, from userid 112) id CB9181F071; Mon, 7 Dec 2020 12:25:00 -0500 (EST) 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=ham 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 AD7FE1EF4B for ; Mon, 7 Dec 2020 12:24:59 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 254FA3851C3D; Mon, 7 Dec 2020 17:24:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 254FA3851C3D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1607361899; bh=IpVhlaZIVWOhhPdpxFiPhzuQyyhcxrRLXSLjIJTDpAY=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=QfdUN8mz4PrVvVEzbFL9cLmlfu1koeP8dn4eVtAs2DYV+Z/gE+OS4+XLbQLA1BJhR hmCOzaQ9QVqeLdRZ2X5ICbYPybaTtIClcqznS6MMo3MpOafh7IbwjXWwpIf6hlyou1 7nqImHiImkGw9+G7/lC0WkXVT7duwhbMvndGY8Wg= Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) by sourceware.org (Postfix) with ESMTPS id 9BD50393BC3E for ; Mon, 7 Dec 2020 17:24:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9BD50393BC3E Received: by mail-qt1-x82b.google.com with SMTP id b9so9942816qtr.2 for ; Mon, 07 Dec 2020 09:24:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=IpVhlaZIVWOhhPdpxFiPhzuQyyhcxrRLXSLjIJTDpAY=; b=kucuLp7LQUChXTpnNSfV05nb617K/jCS5IcsspzZEG8CVgYFf40JZ7orasfls5gYBg VD5aE4tEl5QXjWYJ4c37PFYsSBR3f8lKoQu4vTTN+EMgh9xsK2Jv9P5Q8KIPzpbnxIbP Ng1Qq3BLbRQG3gPave+E2t0HnFzy7pD5fyjVllx+u8LfZA1EyTrpeq5ELkenB/5kD8zu ReCOYN+hKXUFINlMSUAE5M7682xF6a55IwaBZO2pUnLm9uh0a+4HJ4LEU+4ggLlQfDZ+ 44kzl6ydnflyuoavqTsyL7Ec0zIelSfzXwbv8j0HRhP80evlA3bgZeGsZUpnHk0AJIIZ jqSg== X-Gm-Message-State: AOAM533AYD8wK9IiNfQe3tvfD64XSeydCHdZOMuHn8g82SKDHirA1t+S 21THJzdNRD25Ow+lBw71nKKImQ== X-Google-Smtp-Source: ABdhPJwea8qeOCVT7EQNYvf49I5bXJW393wbGRau4f5yQNnV7eMHMRBxaPdnsY2o9lVR8B2+QHI2Ug== X-Received: by 2002:ac8:1282:: with SMTP id y2mr7203427qti.283.1607361895181; Mon, 07 Dec 2020 09:24:55 -0800 (PST) Received: from ?IPv6:2804:7f0:8284:370e:cba:9844:31b8:6c2a? ([2804:7f0:8284:370e:cba:9844:31b8:6c2a]) by smtp.gmail.com with ESMTPSA id z133sm13098696qka.20.2020.12.07.09.24.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Dec 2020 09:24:54 -0800 (PST) Subject: Re: [PATCH 5/8] gdb/riscv: introduce bare metal core dump support To: Andrew Burgess References: <5ba628c1042f3000947a1f2a6f9e24cf46573fa3.1606930261.git.andrew.burgess@embecosm.com> <20201207151702.GK2729@embecosm.com> <36bed17a-6012-a5d9-a29c-64e9cbbef640@linaro.org> <20201207165836.GM2729@embecosm.com> Message-ID: <615830c3-4ccb-cfd6-3721-0123d6c4b56a@linaro.org> Date: Mon, 7 Dec 2020 14:24:33 -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: <20201207165836.GM2729@embecosm.com> 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 Cc: Fredrik Hederstierna , binutils@sourceware.org, gdb-patches@sourceware.org, Paul Mathieu Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 12/7/20 1:58 PM, Andrew Burgess wrote: > * Luis Machado [2020-12-07 12:58:19 -0300]: > >> On 12/7/20 12:17 PM, Andrew Burgess wrote: >>> * Luis Machado [2020-12-02 15:12:26 -0300]: >>> >>>> CC-ing paulmathieu@google.com and fredrik.hederstierna@verisure.com, who >>>> were also looking into supporting bare metal ARM core files. >>>> >>>> Just a quick note... >>>> >>>> Back in October we pondered about this and it looked reasonable, at the >>>> time, to put some effort into documenting the format (unlike the current >>>> Linux core file format, which lacks good documentation). >>>> >>>> My take on it is that we need to settle on a format that works for multiple >>>> architectures. >>> >>> Hi Luis, >>> >>> Thanks for your feedback, I'd love to better understand what you are >>> proposing here. >> >> Sure. What I'm proposing here is the same I proposed in this thread about >> ARM bare metal core files... >> >> https://sourceware.org/pipermail/gdb-patches/2020-October/172617.html >> >> ... and also suggested by Simon here: >> >> https://sourceware.org/pipermail/gdb-patches/2020-October/172270.html >> >> In summary, we should document what a bare metal core file is, what pieces >> it is expected to contain (registers, target descriptions, hardware >> information, execution environment etc) and what format it will be in. >> >>> >>> Could you expand a little on why we need a format that supports >>> multiple architectures (i.e. what benefits will this bring)? And how >>> this would be different to the approach taken here >> >> Having a common format makes it easier to maintain the code and expand the >> features when needed. This is not different from the Linux core file we have >> today. The Linux core file is a common format. >> >> But unlike Linux core files, which have less than ideal documentation and >> specifications, we want to take this opportunity to start clean and to >> document everything required to have a proper bare metal core file. >> >> I think this initial definition and documentation will benefit developers >> moving forward. >> >> Does that make it more clear? > > Not really. I'll go read the various threads that you referenced and > see come back once I have more specific questions. > > Thanks for the pointers. > > Andrew > I'm sorry that did not clarify things, but there isn't much more than that really. All I'm suggesting (up to you to accept it) is that we clarify/coordinate with the interested parties on what is needed for bare metal core files and document it properly (I don't think code is proper documentation). Clearly there are more folks interested in this.