From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by sourceware.org (Postfix) with ESMTPS id 808D23896C38 for ; Mon, 7 Dec 2020 16:58:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 808D23896C38 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-x343.google.com with SMTP id a6so12050354wmc.2 for ; Mon, 07 Dec 2020 08:58:39 -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=A9mJNIHxO1Z9LN2PSN0wqMiy/Cox+LWtUgGHDm/twdc=; b=EfkDVTIZyk+yT+wEHW4qfWp/MN7YeNrpk6JjVPQYxn/9W6FT7zO59ZlFUT2RHs0nXy lz7UMgvCyPa8h4CF7J23qVD34C/QP8fsYcwjIlcgI8eiVp6IRrtJeX5WVsey3jCB35zc jdRWjQAdmy8p8+CcHs+xXg5hX6G+sKJh+65OCqQJPnWRd70izqP3h6+f1qCJHiKzHfIY tEM6WmmraI5BWG416azgvws+Ed8492Tuj3eEC90fDiSsl77uxyMdXt9EuGgUB1N8zxjm EP0yAJVXd9YUfiG4cxmr+VZwKe/q3fQ57Ue5YfsXOIvk98irQIaOkj2lwueWYfGhw2dN DUjA== 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=A9mJNIHxO1Z9LN2PSN0wqMiy/Cox+LWtUgGHDm/twdc=; b=rcWiCSxHba6PDp0wQRVhB3mQc2WYf7oODB32OyNYWw6050B29PspTjwzSSXoM7//V6 DSIvUcrG5LUs/e27mRwad5hgJo9ceE5cKtrw3ORYm+THL5VxTAcE2p4awIdvXxkey0aQ 9ki/hOAyJ16OEAW7Za7FYiBmgCDswI9QiE5/qIQEoAMWknrGjZDFayulBTYOsmclwRly e2zTbUw+NT2eeOq+9XbZW5XTO7zFPCPa620z2V3jPYRILoe7ixjhBYWMyw/FlXivlfw2 8AyjdX9W0dmtB+Ll54k9jD808dqGHRX/ey+2XlAoTDRxFLyT0QY4gNOeS4IJpDaoD8Pp zpfw== X-Gm-Message-State: AOAM53147jmutPZp3iE04ULIfIbPUAGmsknxA/3/3S1UL5T4otz4jbcO 7w4HjdfqpM20rbsg/ggJiJTpNUv69nQtyA== X-Google-Smtp-Source: ABdhPJzsRoVMXnTrsAD8CbB6gwhXYxvXrEG01wX5EaaBIw1us3KOgi0pccdSh8NaDJhSt+LA/D1JDw== X-Received: by 2002:a1c:df0a:: with SMTP id w10mr19901845wmg.114.1607360318639; Mon, 07 Dec 2020 08:58:38 -0800 (PST) Received: from localhost (host109-154-20-215.range109-154.btcentralplus.com. [109.154.20.215]) by smtp.gmail.com with ESMTPSA id x9sm15738101wru.55.2020.12.07.08.58.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Dec 2020 08:58:37 -0800 (PST) Date: Mon, 7 Dec 2020 16:58: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: <20201207165836.GM2729@embecosm.com> References: <5ba628c1042f3000947a1f2a6f9e24cf46573fa3.1606930261.git.andrew.burgess@embecosm.com> <20201207151702.GK2729@embecosm.com> <36bed17a-6012-a5d9-a29c-64e9cbbef640@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36bed17a-6012-a5d9-a29c-64e9cbbef640@linaro.org> X-Operating-System: Linux/5.8.13-100.fc31.x86_64 (x86_64) X-Uptime: 16:51:54 up 43 days, 7:55, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-5.5 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 16:58:42 -0000 * 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