From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ZWlcI5SpDmCefQAAWB0awg (envelope-from ) for ; Mon, 25 Jan 2021 06:20:52 -0500 Received: by simark.ca (Postfix, from userid 112) id 82F151EF80; Mon, 25 Jan 2021 06:20:52 -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 7B4631E940 for ; Mon, 25 Jan 2021 06:20:50 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D3C813949D80; Mon, 25 Jan 2021 11:20:49 +0000 (GMT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) by sourceware.org (Postfix) with ESMTPS id 292563858C27 for ; Mon, 25 Jan 2021 11:20:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 292563858C27 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-x430.google.com with SMTP id p15so5284310wrq.8 for ; Mon, 25 Jan 2021 03:20:45 -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=t5okWgVPbXrpuS9TYzYhriezelEFK27+ACNYu+WAMlA=; b=JUPzJxSCOYwQs6+eddTi0ZzVcD0kHX9oP1Ag9rSW8FLjiwm7NtBpC6YzJ0Omxyozc+ 2dKO/0549K9CgF0uQYbW0jfH7/DAZGju0VuDFUiTYI2m1xlSmktgxYxQVPCkLdQPAiVL W3qG1gPpbH6myf3VSQp3h3zPMeMKVOZxCl8p/fWLqoBCTbH+OSu1Jym/lUrYMc8NOgGI g1IYOceUPeLOuP7OZPt+jg6hDq03PgpdcDkopGahu4LUHsI+5wP1fc5jSTJ7Nov8ivN9 Qd0sFT7r+3ff6CEkRHNae27V7iMHE0Ws/1TcrjbUgrzHbDOTNHgOqtJ8h+YvfL5EsabY vFkA== 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=t5okWgVPbXrpuS9TYzYhriezelEFK27+ACNYu+WAMlA=; b=ov6XNHPrrR7R8LjQKTVRznZjCzS84/4qzQ93+myHjdXgi1ZA7wKuHnnYt3CzEmdcq2 J80mEFadcxK5PQdIqUlGYqxSAtKfGdCW+PHTLVmqtEKuc/DW/MwbhXGlZhnKZiZcX99O XwHQkI97tD5JVFrlkVLi9lT1arTFdOHbGgRxX0WYp5UlUn04j4ZOe/EcjV8zBJsA8MxJ kTgfpJ3TVHArWtAaqqQkR8wx3g/wCtNffc8vbWGX8nM7+EnNWBz4PTuUUL/GBT8bDKYl xKdCIV5k+c+jCQK12a2k/wRclOKnwqcssajBTtvLYL+FzkTvKLojEaiSS8smWKh8onws eErQ== X-Gm-Message-State: AOAM5328GVLnSqGni5a2VQK+ErvutlguDshgWFH8M7K2R+LxysoULzYb F0XuI5IBcz+XY7kRXvpMSpA66LVWhyyeoQ== X-Google-Smtp-Source: ABdhPJzzQx4YKR7N/5aXp3uL/Ds82SuQwi/mEg3iaLRQ69xeqzhaNTl2nZ9zMJxH2Z6kmtly+v2LKQ== X-Received: by 2002:a05:6000:10cd:: with SMTP id b13mr355789wrx.163.1611573644172; Mon, 25 Jan 2021 03:20:44 -0800 (PST) Received: from localhost (host86-166-129-180.range86-166.btcentralplus.com. [86.166.129.180]) by smtp.gmail.com with ESMTPSA id j13sm20321402wmi.24.2021.01.25.03.20.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Jan 2021 03:20:43 -0800 (PST) Date: Mon, 25 Jan 2021 11:20:42 +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: <20210125112042.GE265215@embecosm.com> References: <5a9bb029efd1737d81d1e9ff0e82f359d4267113.1611172468.git.andrew.burgess@embecosm.com> <20210122193004.GB265215@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: 10:52:19 up 47 days, 15:36, 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-25 10:11:42 +0000]: > > -----Original Message----- > > From: Andrew Burgess > > Sent: Friday, January 22, 2021 8:30 PM > > To: Strasuns, Mihails > > Cc: gdb-patches@sourceware.org; binutils@sourceware.org; Fredrik > > Hederstierna > > Subject: Re: [PATCHv2 2/9] bfd/binutils: support for gdb target descriptions > > in the core file > > > > * 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. > > I have meant that even for a barebone platform that doesn't have any > native core dump capabilities it theoretically can be added through > firmware - and GDB would want to support that format too. Sure, but for some arbitrary format that would require significant change in both BFD and GDB probably. Certainly in the past when I've worked with various non-standard dump formats its been easier to write a tool that converts the format to ELF + NOTES and then load that in the normal way. But I don't see the connection between this and adding target descriptions to GDB generated dumps. > From you description below it seems impractical to worry about it > right now though. I'm more worried that I don't understand what I should be worried about :-/ > > > 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? > > I don't have a strong preference here, it is probably fine as it > is. GDB test suite covers both native core and a generated one as > separate test cases, correct? Yes I believe that there are at least some tests that rely on the OS to generate a core file. > Context: I am currently looking into core dump support for Intel > GPUs and using generate-core as a convenient way to quickly iterate > through the different format prototypes. > > However it is not affected by your patch, I was more > curious/concerned about a general direction here. For me personally, I would be happy with GDB adding any additional information that it knows about the target into a generated core file. I'd be willing to accept that this might mean that a GDB generated core file is more informative than a native core file. I'd also accept that we might want to look at ways to derive the same information for a core file that wasn't generated by GDB. I'd be happy for both mechanisms to co-exist. Others might disagree - I'm happy with that too :) After some thought though, I have made one change to this patch. In the version below the target description is generated with a note name of 'GDB' instead of 'CORE'. This is then checked when the note is read back in. This should (hopefully) prevent conflicts in the future, if the note type (0xff000000) is ever reused by some other core file producer. Thanks, Andrew --- commit 9101b8a935dfe716fd978ef3e47624d0f8956582 Author: Andrew Burgess Date: Fri Nov 27 15:41:37 2020 +0000 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. 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. The new note is given the name 'GDB' and a type NT_GDB_TDESC. This should hopefully protect us if there's ever a reuse of the number assigned to NT_GDB_TDESC by some other core file producer. It should also, hopefully, make it clearer to users that this note carries GDB specific information. bfd/ChangeLog: * elf-bfd.h (elfcore_write_gdb_tdesc): Declare new function. * elf.c (elfcore_grok_gdb_tdesc): New function. (elfcore_grok_note): Handle NT_GDB_TDESC. (elfcore_write_gdb_tdesc): New function. (elfcore_write_register_note): Handle NT_GDB_TDESC. binutils/ChangeLog: * readelf.c (get_note_type): Handle NT_GDB_TDESC. include/ChangeLog: * elf/common.h (NT_GDB_TDESC): Define. diff --git a/bfd/elf-bfd.h b/bfd/elf-bfd.h index 15206b4e876..4dce8114c0f 100644 --- a/bfd/elf-bfd.h +++ b/bfd/elf-bfd.h @@ -2797,6 +2797,8 @@ extern char *elfcore_write_aarch_pauth (bfd *, char *, int *, const void *, int); extern char *elfcore_write_arc_v2 (bfd *, char *, int *, const void *, int); +extern char *elfcore_write_gdb_tdesc + (bfd *, char *, int *, const void *, int); extern char *elfcore_write_lwpstatus (bfd *, char *, int *, long, int, const void *); extern char *elfcore_write_register_note diff --git a/bfd/elf.c b/bfd/elf.c index 84a5d942817..5b1adf17d8d 100644 --- a/bfd/elf.c +++ b/bfd/elf.c @@ -9912,6 +9912,12 @@ elfcore_grok_arc_v2 (bfd *abfd, Elf_Internal_Note *note) return elfcore_make_note_pseudosection (abfd, ".reg-arc-v2", note); } +static bfd_boolean +elfcore_grok_gdb_tdesc (bfd *abfd, Elf_Internal_Note *note) +{ + return elfcore_make_note_pseudosection (abfd, ".gdb-tdesc", note); +} + #if defined (HAVE_PRPSINFO_T) typedef prpsinfo_t elfcore_psinfo_t; #if defined (HAVE_PRPSINFO32_T) /* Sparc64 cross Sparc32 */ @@ -10570,6 +10576,13 @@ elfcore_grok_note (bfd *abfd, Elf_Internal_Note *note) else return TRUE; + case NT_GDB_TDESC: + if (note->namesz == 4 + && strcmp (note->namedata, "GDB") == 0) + return elfcore_grok_gdb_tdesc (abfd, note); + else + return TRUE; + case NT_PRPSINFO: case NT_PSINFO: if (bed->elf_backend_grok_psinfo) @@ -11951,6 +11964,18 @@ elfcore_write_arc_v2 (bfd *abfd, note_name, NT_ARC_V2, arc_v2, size); } +char * +elfcore_write_gdb_tdesc (bfd *abfd, + char *buf, + int *bufsiz, + const void *tdesc, + int size) +{ + const char *note_name = "GDB"; + return elfcore_write_note (abfd, buf, bufsiz, + note_name, NT_GDB_TDESC, tdesc, size); +} + char * elfcore_write_register_note (bfd *abfd, char *buf, @@ -12035,6 +12060,8 @@ elfcore_write_register_note (bfd *abfd, return elfcore_write_aarch_pauth (abfd, buf, bufsiz, data, size); if (strcmp (section, ".reg-arc-v2") == 0) return elfcore_write_arc_v2 (abfd, buf, bufsiz, data, size); + if (strcmp (section, ".gdb-tdesc") == 0) + return elfcore_write_gdb_tdesc (abfd, buf, bufsiz, data, size); return NULL; } diff --git a/binutils/readelf.c b/binutils/readelf.c index 5df51086226..feb458877c8 100644 --- a/binutils/readelf.c +++ b/binutils/readelf.c @@ -18296,6 +18296,8 @@ get_note_type (Filedata * filedata, unsigned e_type) return _("NT_PRPSINFO (prpsinfo structure)"); case NT_TASKSTRUCT: return _("NT_TASKSTRUCT (task structure)"); + case NT_GDB_TDESC: + return _("NT_GDB_TDESC (GDB XML target description)"); case NT_PRXFPREG: return _("NT_PRXFPREG (user_xfpregs structure)"); case NT_PPC_VMX: diff --git a/include/elf/common.h b/include/elf/common.h index e7d55ae0782..e6e9c278faa 100644 --- a/include/elf/common.h +++ b/include/elf/common.h @@ -677,6 +677,10 @@ #define NT_SIGINFO 0x53494749 /* Fields of siginfo_t. */ #define NT_FILE 0x46494c45 /* Description of mapped files. */ +/* The range 0xff000000 to 0xffffffff is set aside for notes that don't + originate from any particular operating system. */ +#define NT_GDB_TDESC 0xff000000 /* Contains copy of GDB's target description XML. */ + /* Note segments for core files on dir-style procfs systems. */ #define NT_PSTATUS 10 /* Has a struct pstatus */