From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) by sourceware.org (Postfix) with ESMTPS id 55F8C393BC0B for ; Mon, 7 Dec 2020 18:11:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 55F8C393BC0B 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-wr1-x442.google.com with SMTP id u12so13735407wrt.0 for ; Mon, 07 Dec 2020 10:11:40 -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=eYlDwTh+9LS1sglU7aKfTawYYtGKncmX8hweTFL7h4U=; b=Px8K5qY4wguN3u2La83u4NxZ6UE/3Mhuxse99BOJ1XsOUqAOtDkNwaapt4LHYKcucD 4EJunMRCfehA5k7KSRkavgG8ilyu7gQRWLAX2h+8skCasMDnhvVLQDvEFb54M9rn0LMK vace7YEVtxDSqkAl10zw+bKTT9MpDMHVb+YZFlgC6r5eFYrWEuO2m1AlnJWDs9bTj5mV 8Wq9DcEvlb1mCfgo6TlOFnOFgXBXGSHhrVfgIIxbevrqeM+bX38T+0ywgIIDwK07qIjw vWm1rZCX3VskiiOFNGfeshBwdiPcAmYEJe+d+mfpVkmbz6TTJwWzvEObYGboNZSbu5Gk EUCA== 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=eYlDwTh+9LS1sglU7aKfTawYYtGKncmX8hweTFL7h4U=; b=bQgiRGvN//Q3ov7Kuf9JjQo3kk1/7R+KMjLfX3nfab1+9Pk+j+6lzN4/1TljDYdgvw VpcDhwfcfuXNJhD9A1q2qPfF6WOLUHnXi3O63HPqo65qiz1TLF97LRIjLQigrIBzcAd5 XWtouOc6W7ZxEEh02xi79UVde9ySG4Y+1PmqD9AVCGK3JzahMXmdvMtRvLxpgnUp+xxi tgZMKFrYifKRNpdz0bWyzVNpZOSMkIgvL8104NZH41YJ4p8JKXJjvgW5q8MfYys52hNs 8GBlHzVyzMZe9bU4sJUqt/8+e5wJy/2/97GZaCct1siE1hPJehhdv4xBfMZih26fd90a K9iw== X-Gm-Message-State: AOAM532oJ/RCODtp/aAJiFFPAtAWGVR7ExUs8J2k9WOuI/aSInAx85m6 M/uYMnHPnBYANA2oXCzuKiLFuA== X-Google-Smtp-Source: ABdhPJyN7n3pBiu3KHQCLepqGF5Gd6hWfGAUhJEN9uv3d5K5/QcDZ5bTxQ3SA/tfIpyZgvvY7+cw4A== X-Received: by 2002:adf:c387:: with SMTP id p7mr11088242wrf.95.1607364699372; Mon, 07 Dec 2020 10:11:39 -0800 (PST) Received: from localhost (host109-154-20-215.range109-154.btcentralplus.com. [109.154.20.215]) by smtp.gmail.com with ESMTPSA id q1sm15904848wrj.8.2020.12.07.10.11.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Dec 2020 10:11:38 -0800 (PST) Date: Mon, 7 Dec 2020 18:11:36 +0000 From: Andrew Burgess To: Luis Machado Cc: binutils@sourceware.org, gdb-patches@sourceware.org, Paul Mathieu , Fredrik Hederstierna Subject: Re: [PATCH 5/8] gdb/riscv: introduce bare metal core dump support Message-ID: <20201207181136.GN2729@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <615830c3-4ccb-cfd6-3721-0123d6c4b56a@linaro.org> X-Operating-System: Linux/5.8.13-100.fc31.x86_64 (x86_64) X-Uptime: 17:49:53 up 43 days, 8:53, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 18:11:42 -0000 * 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. 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. Thanks, Andrew [1] https://sourceware.org/pipermail/gdb-patches/2020-October/172845.html [2] https://sourceware.org/pipermail/gdb-patches/2020-October/172721.html