From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) by sourceware.org (Postfix) with ESMTPS id 5353B3896824 for ; Mon, 7 Dec 2020 14:38:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5353B3896824 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-x344.google.com with SMTP id w206so47941wma.0 for ; Mon, 07 Dec 2020 06:38:32 -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=+IvOMrEastx5KUGYqWtF0pnaA5DOP1uAU85erv5UP1Y=; b=EOMFEyN/YKrKRYpQNER91BKq3TWtgu/NhA1winW+NK3BjPr5p7CHu9NKgcwbCFH+88 B+SbOzgVUGaj1CoNpyUaUhrGhoXt0KZYMAL6YzfEWdFvTi8DGJMhEIEi3GTTXyuDWxTJ KzX3Nf1V5c53AzqKmNodczuCx0KloWIuvtPlBm+Pbc6BQBmadNY0lexOUzjCaqw23rru ouiIcEVeypoTW9HpckYd19K8MBuK0JXIEQBSKYARXqBpwlZ6CvDZfw8fNtx3ouFYChNm RUXHmJl9+km+GuRXTqlolHPIJRtFoDfxAtId76U/R4zk8VufkAIwVETKij9PxmrQeGbk yGFg== 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=+IvOMrEastx5KUGYqWtF0pnaA5DOP1uAU85erv5UP1Y=; b=beBEbdC2gi5/zshPldiVewvetR4MTboi54YBP2CvULHT/TcDfpb1Ed6xW57qvYn3Xk UwIvv0VrMj4K5yivGXI5F1d05BPHOYCXBlf1xIUKVQ29LcD5O1YWbYXR2kE6cwuiC1UI QBHFGj9NyU0s+EGvEb8BonVKGWw5K2aw8cZoNXpBQ6+k7etCkM6zYYovgKfsZMGrn0H9 e09nTFw118IidQhJ9Bn/CaEaE5xTlChSH59cQ72q2j8I6vXCs5PnXDe9EJGuG+/s3bZ/ CFxGF7zFZjl4h0tmVusg/Kbcofl7d7pg/q6Vlxi5ezUTScWveobp1ycAT+CIUrK8vxZl WrxQ== X-Gm-Message-State: AOAM531IAlwuogslH2A0eJdOE/6t8R6gQTvFz2OCTADmEOnovUj+QjLi CagtDqMSvtZKdR0n3vPLYT7pL+S7qn1Bew== X-Google-Smtp-Source: ABdhPJyNM2YDAsVKsZo30HUnJs++5jGPoOFp+ey2RkwaAXX1GQvLE/zip7Yt/LE2aMKFue2lnDssRw== X-Received: by 2002:a1c:98c7:: with SMTP id a190mr18769796wme.184.1607351911407; Mon, 07 Dec 2020 06:38:31 -0800 (PST) Received: from localhost (host109-154-20-215.range109-154.btcentralplus.com. [109.154.20.215]) by smtp.gmail.com with ESMTPSA id b83sm14945883wmd.48.2020.12.07.06.38.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Dec 2020 06:38:30 -0800 (PST) Date: Mon, 7 Dec 2020 14:38:29 +0000 From: Andrew Burgess To: Tom Tromey Cc: binutils@sourceware.org, gdb-patches@sourceware.org Subject: Re: [PATCH 3/8] gdb: write target description into core file Message-ID: <20201207143829.GI2729@embecosm.com> References: <87pn3qaaoo.fsf@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87pn3qaaoo.fsf@tromey.com> X-Operating-System: Linux/5.8.13-100.fc31.x86_64 (x86_64) X-Uptime: 14:34:47 up 43 days, 5:37, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-13.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=unavailable 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 14:38:33 -0000 * Tom Tromey [2020-12-03 13:36:55 -0700]: > >>>>> "Andrew" == Andrew Burgess writes: > > Andrew> + if (bfd_get_section_contents (core_bfd, tdesc_note_section, > Andrew> + contents.data(), (file_ptr) 0, > > Missing space after "data". > > I suppose the trailing \0 is guaranteed to be in the section data. Well, it should if the content is well formed, this can be seen in the change to `write_gcore_file_1` where the length is extended to include the null. However, you make a good point. The content is coming from outside GDB and could be corrupt, so we shouldn't assume that there is a null present. As such I've updated the patch so that we force a null at the end when reading in the target description, this should ensure GDB doesn't read outside the section contents. Thanks Andrew --- commit 10e9c51c13a5f1da3ad53fc987d90cbffa8501a9 Author: Andrew Burgess Date: Fri Nov 27 15:41:52 2020 +0000 gdb: write target description into core file When a core file is created from within GDB add the target description into a note within the core file. When loading a core file, if the target description note is present then load the target description from the core file. The benefit of this is that we can be sure that, when analysing the core file within GDB, that we are using the exact same target description as was in use at the time the core file was created. In future commits I intend to add support for bare metal core dumps for some targets. These core dumps will include auxiliary registers, the availability of which can only be established by looking at the target description. gdb/ChangeLog: * corelow.c: Add 'xml-tdesc.h' include. (core_target::read_description): Load the target description from the core file when possible. * gcore.c: Add 'gdbsupport/tdesc.h' include. (write_gcore_file_1): Write out the target description. diff --git a/gdb/corelow.c b/gdb/corelow.c index 4c1f068053d..f00770080d8 100644 --- a/gdb/corelow.c +++ b/gdb/corelow.c @@ -49,6 +49,7 @@ #include #include #include "gdbcmd.h" +#include "xml-tdesc.h" #ifndef O_LARGEFILE #define O_LARGEFILE 0 @@ -1000,6 +1001,29 @@ core_target::thread_alive (ptid_t ptid) const struct target_desc * core_target::read_description () { + /* If the core file contains a target description note then we will use + that in preference to anything else. */ + bfd_size_type tdesc_note_size = 0; + struct bfd_section *tdesc_note_section + = bfd_get_section_by_name (core_bfd, ".gdb-tdesc"); + if (tdesc_note_section != nullptr) + tdesc_note_size = bfd_section_size (tdesc_note_section); + if (tdesc_note_size > 0) + { + gdb::char_vector contents (tdesc_note_size + 1); + if (bfd_get_section_contents (core_bfd, tdesc_note_section, + contents.data (), (file_ptr) 0, + tdesc_note_size)) + { + /* Ensure we have a null terminator. */ + contents [tdesc_note_size] = '\0'; + const struct target_desc *result + = string_read_description_xml (contents.data ()); + if (result != NULL) + return result; + } + } + if (m_core_gdbarch && gdbarch_core_read_description_p (m_core_gdbarch)) { const struct target_desc *result; diff --git a/gdb/gcore.c b/gdb/gcore.c index 9a22b1005f0..bf6f44213bb 100644 --- a/gdb/gcore.c +++ b/gdb/gcore.c @@ -38,6 +38,7 @@ #include "gdbsupport/gdb_unlinker.h" #include "gdbsupport/byte-vector.h" #include "gdbsupport/scope-exit.h" +#include "gdbsupport/tdesc.h" /* The largest amount of memory to read from the target at once. We must throttle it to limit the amount of memory used by GDB during @@ -82,6 +83,25 @@ write_gcore_file_1 (bfd *obfd) note_data = gdbarch_make_corefile_notes (target_gdbarch (), obfd, ¬e_size); + /* Append the target description to the core file. */ + const struct target_desc *tdesc = gdbarch_target_desc (target_gdbarch ()); + const char *tdesc_xml = tdesc_get_features_xml (tdesc); + if (tdesc_xml != nullptr && *tdesc_xml != '\0') + { + /* Skip the leading '@'. */ + if (*tdesc_xml == '@') + ++tdesc_xml; + + /* Include the null terminator in the length. */ + size_t tdesc_len = strlen (tdesc_xml) + 1; + + /* Now add the target description into the core file. */ + note_data.reset (elfcore_write_register_note (obfd, + note_data.release (), + ¬e_size, ".gdb-tdesc", + tdesc_xml, tdesc_len)); + } + if (note_data == NULL || note_size == 0) error (_("Target does not support core file generation."));