From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id khQuF8B7zl9ETQAAWB0awg (envelope-from ) for ; Mon, 07 Dec 2020 14:00:16 -0500 Received: by simark.ca (Postfix, from userid 112) id 5400B1F071; Mon, 7 Dec 2020 14:00:16 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [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 8754D1EF4B for ; Mon, 7 Dec 2020 14:00:15 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BDF3D393D01A; Mon, 7 Dec 2020 19:00:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BDF3D393D01A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1607367614; bh=MEkMLokjyrd85yJmFQN+ku6KgmdGF6sawY3UtVIcsfk=; 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=SrGpE01vYlwz9qMODIUc9p7fxGRMPvSg//LjQ+G+LEVEYaeohtrNZApzbx4rLs5Id B6Kpb68v7rJRO46+I3FhKmUfMFlUO1JDH2AE77dwtt1wl04NoPlLob1IKWR7t6vVGf a2Uj9sko5xXvwkfYUNX/HbIS2lNItkVA3TQ4uUFg= Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) by sourceware.org (Postfix) with ESMTPS id D097B3896837 for ; Mon, 7 Dec 2020 19:00:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D097B3896837 Received: by mail-qk1-x731.google.com with SMTP id w79so2500364qkb.5 for ; Mon, 07 Dec 2020 11:00:10 -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=MEkMLokjyrd85yJmFQN+ku6KgmdGF6sawY3UtVIcsfk=; b=MXF4hMxKm+zqxPtcRuoKsBxxRtzEhNFvLgKSV2vyYt4HzHyWfZ3ZlSWr4XHQ2pe8Q7 9Ht4y95lxD+QHIPrbGicsm8ffdSt88a7jcNOACO2nA8OBvfGbdUhyKApgJFbn78wP5U7 2gl41e3bAKjMwhXSs56z4ec+Kk5kx1NsD83QThF9n/UWK4LG9sMyo+inPF+hqFVxjn1f /51YHNRqC0/M+Hj+xe3ZVywHzIeHB3StdLuXQBh4zCuWODiQ0EhcguvmvHciSdL4b5R6 JK91WGxZAbmwtKhhkLsPoyo/7mOzpePbbtZYme8zNACuohze9ee2SXkwqpr+k5yrqdZH jWmw== X-Gm-Message-State: AOAM531QwmFIGY2lfqTPL2URFXy0wdVIS6mAIgYyKpKUh6zHzvMOiZb8 7eC8ayBd00uYy67IVtB0HQcbiw== X-Google-Smtp-Source: ABdhPJxLqrfb2DP/ei3cuKUXbgNzWF57Ae59O2KuOhKHY3wcfnMJi89gjiWOc3auy/KayAY9whRM8A== X-Received: by 2002:a37:5103:: with SMTP id f3mr25566435qkb.460.1607367610246; Mon, 07 Dec 2020 11:00:10 -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 z30sm12709124qtc.15.2020.12.07.11.00.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Dec 2020 11:00:09 -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> <615830c3-4ccb-cfd6-3721-0123d6c4b56a@linaro.org> <20201207181136.GN2729@embecosm.com> Message-ID: <3595d9b8-e26c-5ed4-8906-4ee3519a120e@linaro.org> Date: Mon, 7 Dec 2020 16:00:06 -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: <20201207181136.GN2729@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 3:11 PM, Andrew Burgess wrote: > * Luis Machado [2020-12-07 14:24:33 -0300]: > >> 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). > > Sure. > > What I don't understand is you talk about creating "a format that > works for multiple architectures". > > Current Linux/FreeBSD core files are a container (often ELF) with > NOTES containing additional information. > > By format are you suggesting we come up with something non-ELF? I > doubt this is the case, but if so, why would we want to do this? > > Or are you suggesting some kind of coordination for note > names/numbers? But I don't see how this is different to what we have > right now. Sorry, I think you're reading too deeply into what I said. All I've suggested is to let the interested parties know you're doing this work, get their feedback on the strategy for dumping data for bare metal targets (I've cc-ed two of them, so they can chime in), see if that works for them with little to no extra work, and document it in a formal way (say, in gdb.texinfo). That's it. I'm not talking about code, patch or implementation. I'm talking about a bare metal core file draft design that everyone is happy with, and based on which folks can go and implement what they want without having to dig into GDB's code for that. You have the RISC-V implementation (it looks good to me FWIW), that's fine. But what is it implementing? It is not documented anywhere, is it? It is just following whatever Linux is doing, which is already badly documented. > > I'm tight on time right now, but I skimmed the threads you linked, I > looked at Fredrik's v4 patch[1] from Oct-25. This patch had some of > the boiler-plate code lifted into a common file, which I could > integrate into my series, but otherwise the patches are pretty > similar. > > You hadn't followed up to Fredrik's v4 patch[1], but based on your > comments to the v2 patch[2] I'm guessing you're still not happy with > v4 (please do correct me if this guess is wrong). > > In your comments to Fredrik's v2 patch[2] you say: > > We should really discuss what the generic core file format for > bare-metal targets will look like before having a possible patch to > implement it. At least that's my take on it. > > To which there's no follow up. Is there a mail I've missed where you > sketch out your ideas for what this generic format might look like? > > How about I propose something here to get the ball rolling, and you > (or others) can suggest improvements, or ask for clarifying questions: > > - A container file format, lets say ELF, > - Loadable sections corresponding to the loaded memory contents, > - A NOTES section containing auxiliary information, e.g. > + Threads (thread per core?) > + Registers for each thread > > Unsurprisingly this lines up with what I've proposed, and if I'm > reading the patch correctly, with what Fredrik is also proposing.