From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3144 invoked by alias); 16 May 2017 14:01:08 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 3106 invoked by uid 89); 16 May 2017 14:01:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Fair, arrangement, story, person X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 May 2017 14:01:06 +0000 Received: from hhmail02.hh.imgtec.org (unknown [10.100.10.20]) by Forcepoint Email with ESMTPS id A8B1E379BEB2; Tue, 16 May 2017 15:01:03 +0100 (IST) Received: from [10.20.78.22] (10.20.78.22) by hhmail02.hh.imgtec.org (10.100.10.21) with Microsoft SMTP Server id 14.3.294.0; Tue, 16 May 2017 15:01:05 +0100 Date: Tue, 16 May 2017 14:01:00 -0000 From: "Maciej W. Rozycki" To: Yao Qi CC: Subject: Re: [PATCH] Move initialize_tdesc_mips* calls from mips-linux-nat.c to mips-linux-tdep.c In-Reply-To: <86a86k7kmg.fsf@gmail.com> Message-ID: References: <1494324439-15918-1-git-send-email-yao.qi@linaro.org> <86a86k7kmg.fsf@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2017-05/txt/msg00348.txt.bz2 On Wed, 10 May 2017, Yao Qi wrote: > > Why? These descriptions are only used in the native case, otherwise > > gdbserver supplies its own. The current arrangement has worked for some > > 12 years now. > > Because I want these target descriptions be available in -tdep.c files > so that I can test them without running the test on a mips-linux > machine. > > Long story is I changed the output of "maint print c-tdesc", and I add a > test to make sure these generated C files (by this command) is still > equivalent to the xml files. If it is not clear to you, I can include > this patch in my whole patch series. Fair enough, although can you please add such details to the patch description (as it appears in the actual commit), so that also someone looking at it in several years' time have a chance to understand the change without the need to wade through mailing list archives? It is often the case that a change has to be understood long since it has been made and a clear description of the *intent* rather than just a terse ChangeLog entry or code modifications themselves is then invaluable, when the person who made it is no longer available to answer questions or may not remember anymore what exactly the change was about. If as you say this is a part of a set of changes, then I think it will be enough if you include such a description in the first change and then only refer to it by commit ID and heading from any subsequent changes, in addition to any change-specific details possibly required. Maciej