From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by sourceware.org (Postfix) with ESMTP id 070D13948800 for ; Thu, 11 Jun 2020 14:24:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 070D13948800 Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-101-sKl3PoqkOgSfBYe_lh6QnQ-1; Thu, 11 Jun 2020 10:24:29 -0400 X-MC-Unique: sKl3PoqkOgSfBYe_lh6QnQ-1 Received: by mail-wr1-f69.google.com with SMTP id c14so2613034wrm.15 for ; Thu, 11 Jun 2020 07:24:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6eB4dqKqeqllpiGWrSPRRHj14CXISuvb9jPt4sm/E2A=; b=kSgZvDZ24iYQOsE+aRxCx7zvNg7QFHvj+db0A4Id3tQnlmB5KYGW9fGth2ku3VsLWT yz6b5wWJEQO9Rt2QyMNtfgRK5XM0WOULVyiOMhCEK8SaogAEYJmcM9nCIGWmuf+uILST exh9dkdwZKW33zgCI3q/g1vmm6e+eJ+59qKbvuBzKf/ji4GgaqLoT7zhVXqrN0uxdAKV 2txMb2rEQiZ8IIXkR7IwfP3rjMjt71nsSLMw8iuulWfurAkuu/Odr8j+xupCHRZiGMFv jIhUOnVU2VwOV6dK6KfcpDnlLwGw9hKDWi6xJ27JpGEqOWydB9ivYUqFdWF3R2iDpgR7 tT3g== X-Gm-Message-State: AOAM5318oFhUE5QJW/kJrU8wLoBNPV52jINI9SQNpTGeohUdB6JnnBGC GaoCMWm4KOhmghhPBaJMmDvZjZXZXXfb54Hh4UE2YN8FnczzFa1tobYOcSATPeb8x2CHtQL3LrU a4rgSq3dNv+r/2U5797++kQ== X-Received: by 2002:adf:aa42:: with SMTP id q2mr10390098wrd.360.1591885467716; Thu, 11 Jun 2020 07:24:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyDZOyDIqyHLH30L8Z7gbIZ0hLuuzSRDBVcvDlwh8BtAyKC880Ty+5kn7rXZmVfrQZaNpvUNA== X-Received: by 2002:adf:aa42:: with SMTP id q2mr10390079wrd.360.1591885467444; Thu, 11 Jun 2020 07:24:27 -0700 (PDT) Received: from ?IPv6:2001:8a0:f922:c400:56ee:75ff:fe8d:232b? ([2001:8a0:f922:c400:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id 88sm5703598wre.45.2020.06.11.07.24.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Jun 2020 07:24:26 -0700 (PDT) Subject: Re: [PATCH 1/2] gdb: Allow target description to be dumped even when it is remote To: Andrew Burgess References: <3dc13658-f2ab-a76b-ee67-e1b9f343eef1@redhat.com> <20200611140553.GK2737@embecosm.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <3add3481-3581-4819-e165-557a2edd9b2b@redhat.com> Date: Thu, 11 Jun 2020 15:24:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20200611140553.GK2737@embecosm.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-8.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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: 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: , X-List-Received-Date: Thu, 11 Jun 2020 14:24:44 -0000 On 6/11/20 3:05 PM, Andrew Burgess wrote: > * Pedro Alves [2020-06-11 12:33:08 +0100]: > >> On 6/11/20 11:41 AM, Andrew Burgess wrote: >>> The maintenance command 'maintenance print c-tdesc' can only print the >>> target description if it was loaded from a local file, or if the local >>> filename is passed to the maintenance command as an argument. >>> >>> Sometimes it would be nice to know what target description GDB was >>> given by the remote, however, if I connect to a remote target and try >>> this command I see this: >>> >>> (gdb) maintenance print c-tdesc >>> The current target description did not come from an XML file. >>> (gdb) >>> >>> Which is not very helpful. >>> >>> This commit changes things so that if the description came from the >>> remote end then GDB will use the fake filename 'target.xml' as the >>> filename for the description, GDB will then create the C description >>> of the target as if it was in a file 'target.xml'. >>> >>> I originally added this functionality so I could inspect the >>> description passed to GDB by the remote target. After using this for >>> a while I realised that actually having GDB recreate the XML would be >>> even better, so a later commit will add that functionality too. >>> >>> Still, given how small this patch is I thought it might be nice to >>> include this in GDB anyway. >>> >>> While I was working on this anyway I've added filename command >>> completion to this command. >>> >>> gdb/ChangeLog: >>> >>> * target-descriptions.c (maint_print_c_tdesc_cmd): Use fake >>> filename for target descriptions that came from the target. >>> (_initialize_target_descriptions): Add filename command completion >>> for 'maint print c-tdesc'. >>> --- >>> gdb/ChangeLog | 7 +++++++ >>> gdb/target-descriptions.c | 14 ++++++++++---- >>> 2 files changed, 17 insertions(+), 4 deletions(-) >>> >>> diff --git a/gdb/target-descriptions.c b/gdb/target-descriptions.c >>> index 20a3a640f4f..55ea416d69a 100644 >>> --- a/gdb/target-descriptions.c >>> +++ b/gdb/target-descriptions.c >>> @@ -1680,7 +1680,12 @@ maint_print_c_tdesc_cmd (const char *args, int from_tty) >>> error (_("There is no target description to print.")); >>> >>> if (filename == NULL) >>> - error (_("The current target description did not come from an XML file.")); >>> + { >>> + printf_unfiltered (_("The current target description was fetched " >>> + "from the target, using\n'target.xml' as a fake " >>> + "filename.\n\n")); >> >> That "," makes it read a little bit ambiguously. Try reading the sentence >> without the "," to see what I mean: >> >> The current target description was fetched from the target using >> 'target.xml' as a fake filename. >> >> This can be read as GDB having read the remote fake 'target.xml' filename, >> like: >> fetch_available_features_from_target ("target.xml", ops); >> which is what it always does anyway... >> >> I'd suggest a hard period (and line break after the period) instead: >> >> The current target description was fetched from the target. >> Using 'target.xml' as a fake filename. >> >> But, why do we need to provide a fake name at all? Isn't the only use of >> that filename to print it in the comment, here: >> >> /* THIS FILE IS GENERATED. -*- buffer-read-only: t -*- vi:set ro: >> Original: target.xml */ >> >> How about just doing this: > > No, the filename is used in a couple of other places too, object names > are created based on the filename as well. Still I took your idea and > went with it. Ah, missed that. > > The patch below uses 'fetched from target' as the fake filename > instead. I needed one small extra change so that 'fetched from > target' could become 'fetched_from_target' when creating C++ variable > names, but otherwise this seem fine to me. That fixes the case of a filename with spaces, regardless, like "foo bar.xml", as in: (gdb) maint print c-tdesc foo bar.xml Maybe mention that in the commit log. > > How's this? LGTM. Thanks, Pedro Alves