From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id xI9gMMMnC2B5MQAAWB0awg (envelope-from ) for ; Fri, 22 Jan 2021 14:30:11 -0500 Received: by simark.ca (Postfix, from userid 112) id BD4CB1EF80; Fri, 22 Jan 2021 14:30:11 -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.4 required=5.0 tests=DKIM_SIGNED,MAILING_LIST_MULTI, RDNS_NONE,T_DKIM_INVALID,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 2B0CA1E939 for ; Fri, 22 Jan 2021 14:30:11 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DBBF9398E4A8; Fri, 22 Jan 2021 19:30:10 +0000 (GMT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) by sourceware.org (Postfix) with ESMTPS id 4CB553893668 for ; Fri, 22 Jan 2021 19:30:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4CB553893668 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-x432.google.com with SMTP id v15so6134325wrx.4 for ; Fri, 22 Jan 2021 11:30:06 -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=d47bOkyWwGIdFQeP8nRp3UTowqTEkutC7Hjx2jaZb8k=; b=LwhqyU/q+TDBtytFkAvjsLyxbSV9myKHxZBjc1Bxdw6THEilL1EDgRzH1Mq8m/206/ i2GVUcTDX9NgGvt+OHYkeOgE88WSw4Tkkh2iOYHtiCdYdtNImzs6mMnimLulKSoTgJt3 25zTt1Ed8AcB0ftl794bEQc0WeBoP+C5Mqrpe0bNH9hKy67GSFR/jL2vzdB5PcJK69yA 0q6lJN4lZUTiBQi3kgTL/tXvCXxQ9ZggDr9dDDqWbdirTn51DGjCBuG+mrJF36t/NZZY itLXnequuU+9rWifzb/onBVOpnkH3wBydyPHCci3IdzmEYq1Z36Fnv0gP0lEJzLksn64 FXng== 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=d47bOkyWwGIdFQeP8nRp3UTowqTEkutC7Hjx2jaZb8k=; b=ouwnRJHlLxgN3j+DjC3KRfKDcMuyHq+z2yCnvBjWu7pVcFsbXdn+8EMK9JmA5uME00 EIF1WAOnmHoCEtoz178SkyCqBc9XjJiOnXsXL0OOqz61EkhWvG1LS0ukx+FljN8Ib7oB CaenIpQX4/u7gFbXph0cHNXVGthSkmeHkOKAMa+EJFeJiWxEY31HSfdoEtyc1jitwihD VDwAzmPZtWbR3dcA1/iIfDJENNB5DXDZEhmiaT3scUrr4h6m+vhvpu2sWCkSghKiYCkl e7QnLOxtrbwtH0fIZ+0mjPvMHFsNOy970W0mIXY/4cO+bYDZottWKSYvHYKzdxD3O6e1 3JnQ== X-Gm-Message-State: AOAM533qZLTflvvp0XbXCxS5mHuemjY/+YIngWHu1NlyEyDPOJVnPd20 BivoWJnfTbRWpj15ZnZYCXzwnQ== X-Google-Smtp-Source: ABdhPJweO6LCIAz7ywk+xBrlDWuQk3mAvGCX4Nale7Is75NVWXdVGxni5T5zaKIJpzvEdn4N8DR8Ag== X-Received: by 2002:a5d:4d8b:: with SMTP id b11mr6016452wru.215.1611343805511; Fri, 22 Jan 2021 11:30:05 -0800 (PST) Received: from localhost (host109-154-20-185.range109-154.btcentralplus.com. [109.154.20.185]) by smtp.gmail.com with ESMTPSA id u142sm4999341wmu.3.2021.01.22.11.30.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Jan 2021 11:30:04 -0800 (PST) Date: Fri, 22 Jan 2021 19:30:04 +0000 From: Andrew Burgess To: "Strasuns, Mihails" Subject: Re: [PATCHv2 2/9] bfd/binutils: support for gdb target descriptions in the core file Message-ID: <20210122193004.GB265215@embecosm.com> References: <5a9bb029efd1737d81d1e9ff0e82f359d4267113.1611172468.git.andrew.burgess@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux/5.8.13-100.fc31.x86_64 (x86_64) X-Uptime: 19:15:43 up 45 days, 0 min, 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" Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" * Strasuns, Mihails [2021-01-22 10:47:23 +0000]: > > -----Original Message----- > > From: Gdb-patches On Behalf Of > > Andrew Burgess > > Sent: Wednesday, January 20, 2021 9:23 PM > > To: gdb-patches@sourceware.org; binutils@sourceware.org > > Cc: Fredrik Hederstierna > > Subject: [PATCHv2 2/9] bfd/binutils: support for gdb target descriptions in > > the core file > > > > This commit lays the ground work for allowing GDB to write its target > > description into a generated core file. > > > > The goal of this work is to allow a user to connect to a remote target, capture > > a core file from within GDB, then pass the executable and core file to another > > user and have the user be able to examine the state of the machine without > > needing to connect to a running target. > > > > Different remote targets can have different register sets and this information > > is communicated from the target to GDB in the target description. > > Why is it necessary to store a GDB target description for this? Core > files already define machine/arch, same as executable ELFs. There > still can be some register variation between different platform > versions, but it would still need to be denoted somehow in a native > core file. > > My concern is for making a "GDB core file" and a "native core file" > even more different than it is currently on Linux. I guess this is > aimed at a barebone environments where there is currently no native > core dump support at all but even there it is not guaranteed. I was following you until "... but even there it is not guaranteed." I'm not sure what it is that is not guaranteed. Yes, absolutely my interest here is bare metal core dumps, but I don't see including the target description in all core files as a big problem. I'm not aware that GDB was ever aiming to create core dumps that would be identical to kernel produced dumps, just that they should be compatible. Including an extra note should be transparent to any well behaved tool (I'd hope), or at worst maybe a warning about not understanding the note The problem I'm trying to solve is that the RISC-V targets I'm working with have a pretty random collection of control status registers (CSRs), included off-spec registers. I'd like to capture these in the core dump, so the approach I have right now is just dump all of them in target description order. Anyway, back to your concerns... ...would making target description inclusion optional/switchable be enough to alleviate your concerns? Would you rather it was default off, or would you be happy with switchable default on? Thanks, Andrew > > > It is possible for a user to extract the target description from GDB and pass > > this along with the core file so that when the core file is used the target > > description can be fed back into GDB, however this is not a great user > > experience. > > > > It would be nicer, I think, if GDB could write the target description directly > > into the core file, and then make use of this description when loading a core > > file. > > > > This commit performs the binutils/bfd side of this task, adding the boiler > > plate functions to access the target description from within a core file note, > > and reserving a new number for a note containing the target description. > > > > Later commits will extend GDB to make use of this. > Intel Deutschland GmbH > Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Gary Kershaw > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928 >