From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 882 invoked by alias); 2 May 2017 20:16:30 -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 872 invoked by uid 89); 2 May 2017 20:16:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=Sure, honest, stand, interest X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 02 May 2017 20:16:26 +0000 Received: by simark.ca (Postfix, from userid 33) id 3D46E1E4A5; Tue, 2 May 2017 16:16:27 -0400 (EDT) To: Sergio Durigan Junior Subject: Re: [PATCH] Introduce "gdb/configure.nat" (and delete "gdb/config/*/*.mh" files) X-PHP-Originating-Script: 33:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 02 May 2017 20:16:00 -0000 From: Simon Marchi Cc: GDB Patches , Pedro Alves , John Baldwin In-Reply-To: <8737cngise.fsf@redhat.com> References: <20170425202309.15771-1-sergiodj@redhat.com> <8737cngise.fsf@redhat.com> Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.5 X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00029.txt.bz2 On 2017-05-02 15:28, Sergio Durigan Junior wrote: >>> +# Variables defined here: >>> +# >>> +# NAT_FILE >>> +# NATDEPFILES >>> +# NAT_CDEPS >>> +# LOADLIBES >>> +# MH_CFLAGS >>> +# XM_CLIBS >>> +# NAT_GENERATED_FILES >>> +# HAVE_NATIVE_GCORE_HOST >>> +# NAT_EXTRA_FRAGS_FILE >> >> Could you document (if you know it) what each variable does? > > Sure. Here's what I know what them. What do you think? > > # Variables defined here: > # > # NAT_FILE - The header file with definitions for this host Looks good. > # > # NATDEPFILES - The depfiles to be compiled for this host "depfiles" is not so clear I think. Perhaps NATDEPFILES - Source files required for native debugging on this host. > # > # NAT_CDEPS - Dynamic symbols to be exported for libthread_db Looks good. > # > # LOADLIBES - Libraries that will be linked against GDB for this host Don't we usually say the reverse, the program is linked against the libraries? LOADLIBES - Libraries against which GDB will be linked for this host. > # > # MH_CFLAGS - Additional CFLAGS for this host Looks good. > # > # XM_CLIBS - Host-dependent libs to be linked against GDB. Same comment about "linked against". > # NAT_GENERATED_FILES - Generated files by this host by -> for? NAT_GENERATED_FILES - Generated files for this host. > # HAVE_NATIVE_GCORE_HOST - I just noticed that this variable is not defined in Makefile.in. configure.ac AC_SUBST's _TARGET twice, but not _HOST, so I think you confused them. But to be honest, I am also completely confused by what those two variables do. > # NAT_EXTRA_FRAGS_FILE - Extra Makefile fragmentsFile containing extra > fragments of Makefile > # that will be used by this host. That could be shortened to NAT_EXTRA_FRAGS_FILE - Extra Makefile fragments that will be used for this host. Make sure they all end (or don't end) with a period, for consistency. Perhaps someone could shed some light on the obscure variables names? What do the XM_ and MH_ prefixes stand for? What's the difference between XM_CLIBS and LOADLIBES (and why is it called "LIBES"?) ? >> IMO, the interest of having all of this in a single file is to be able >> to factor out common things. A lot of NATDEPFILES are repeated Would >> it be possible to have a switch on ${gdb_host} at the top level, and >> specify all the files specific to OSes but machine-agnostic? For >> example, fork-child.o and inf-ptrace.o probably appear in all the >> linux ports. > > Fair point. I will address what you and Jon mentioned, and resubmit > the > patch with the modifications. Ok. But as John mentioned, it's probably better if this patch is a simple translation of what's already there, and any "optimization" coming in a subsequent patch. It will be easier to track the changes. Thanks, Simon