From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ekl4K1aBzl/1TgAAWB0awg (envelope-from ) for ; Mon, 07 Dec 2020 14:24:06 -0500 Received: by simark.ca (Postfix, from userid 112) id A7BD81F071; Mon, 7 Dec 2020 14:24:06 -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.9 required=5.0 tests=DKIM_SIGNED, MAILING_LIST_MULTI,T_DKIM_INVALID,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 48DC31EF4B for ; Mon, 7 Dec 2020 14:24:05 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6F7F1393D01A; Mon, 7 Dec 2020 19:24:04 +0000 (GMT) Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) by sourceware.org (Postfix) with ESMTPS id 4642E3858028 for ; Mon, 7 Dec 2020 19:24:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4642E3858028 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-wm1-x341.google.com with SMTP id 3so283687wmg.4 for ; Mon, 07 Dec 2020 11:24:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=zvAjONjySIeeOmHVKaQINs2sKMCxAP7Yw79VfqHpjjI=; b=ThuxF5sMSpkAkjACr4QQGmquojDbPDHfI+B4ScuxM6pKkzyhm8b5dipfS2D8gteYvk 5J/vhgoQftIwlR0aGQj9Ik4fzUEA6dWL+Bqj4kxb/1Pft7jFPv6iZVSKk0AC36NGaeHo yKnGDNHnqp12ctMLLMpAgRdiu8AyvewEPkTSNCEzHW3O8UXaQDIEIeD9YK+lMTrH3wLx iEnELL+zbxcdur6FcZnxxXYMhAS4wARZ97tMH3YWFt/CVmuILxyQdVNeB7xV9DeV6Tdo +tfyU3BjfxUMsXpcEY7J53t1p/4fwNt+pkaS9+iv28pM4qnfHh+ZwMXHOzdCrCRn8PG8 yg2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=zvAjONjySIeeOmHVKaQINs2sKMCxAP7Yw79VfqHpjjI=; b=KOYdd8ctcTmYNVi+2aL01Tw7rA3qYLfXq5pwN4All9vijjE0rkXoVQD18bvDgIvzLA V8L05MeugUC40OpATGOs9hWVrx0IfproXgdXbJWYgZN2ChdBOYuYnI8O2lE8TqWtaUOI +cwaL01R9c0povnmIhplTxu50LIP4GmaWFwbgZ2MJJnnoJBuMa9zIYs3EGVeEfOlJnBc et/BJO2ZSB5P5RkTvoWIL6LdJZ8K4AanXUuqm/8of7wrc0M6CgE+jyU2zF68RkukoGDT ixDnXe7gb5/t5yRdphISV3gWx9T9hESLDYR3oUtFrKNu6dxCIy6uvtfOD6UYmacNvmiA 0J7w== X-Gm-Message-State: AOAM531tGz4Pccwd40eyzrZVAHVs9R0B9GMWWwI+zD1jE8q0frho+WeB 2M7mOojDlrdHg7bfbvfJPms9sA== X-Google-Smtp-Source: ABdhPJzxWTfJulxrHD8SEke5FfADFtCvBlr6AW+aKXwvkC1C1n+CCRuczV3W6RtDY/b2YkLIrO5AWA== X-Received: by 2002:a05:600c:2903:: with SMTP id i3mr336289wmd.41.1607369041324; Mon, 07 Dec 2020 11:24:01 -0800 (PST) Received: from localhost (host109-154-20-215.range109-154.btcentralplus.com. [109.154.20.215]) by smtp.gmail.com with ESMTPSA id 65sm14137433wri.95.2020.12.07.11.24.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Dec 2020 11:24:00 -0800 (PST) Date: Mon, 7 Dec 2020 19:23:59 +0000 From: Andrew Burgess To: Luis Machado Subject: Re: [PATCH 5/8] gdb/riscv: introduce bare metal core dump support Message-ID: <20201207192359.GO2729@embecosm.com> 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> <3595d9b8-e26c-5ed4-8906-4ee3519a120e@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3595d9b8-e26c-5ed4-8906-4ee3519a120e@linaro.org> X-Operating-System: Linux/5.8.13-100.fc31.x86_64 (x86_64) X-Uptime: 19:17:39 up 43 days, 10:20, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] 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: , Cc: Fredrik Hederstierna , binutils@sourceware.org, gdb-patches@sourceware.org, Paul Mathieu Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" * Luis Machado [2020-12-07 16:00:06 -0300]: > 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. Oh, OK! That's much smaller in scope then. Jim already asked about getting this documented in a different reply, my plan is to document the RISC-V parts of this into the RISC-V elf abi document (assuming the maintainers of that document accept such a patch). I'll re-review Fredrik's v4 patch and see if there's anything we can share there, though from my first look through we're basically doing the same thing already as that's the only obvious approach to take (assuming the goal is ELF + NOTES). I'll also reread your comments on numbering of the tdesc note and see if there's a better number I can/should propose. Thanks, Andrew > > > > > 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.