From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78115 invoked by alias); 21 Jun 2017 16:22:38 -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 77325 invoked by uid 89); 21 Jun 2017 16:22:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=grasp, our X-HELO: userp1040.oracle.com Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 21 Jun 2017 16:22:35 +0000 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5LGMVsL027863 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Jun 2017 16:22:32 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v5LGMVN5017710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Jun 2017 16:22:31 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v5LGMVQd022379; Wed, 21 Jun 2017 16:22:31 GMT Received: from [192.168.1.74] (/108.88.88.153) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Jun 2017 09:22:30 -0700 Message-ID: <594A9D45.1010604@oracle.com> Date: Wed, 21 Jun 2017 16:22:00 -0000 From: Wei-min Pan User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH v2] gdb: ADI support References: <1497655802-111684-1-git-send-email-weimin.pan@oracle.com> <86o9ti4wa1.fsf@gmail.com> <59496067.5040008@oracle.com> <86d19xhdv0.fsf@gmail.com> In-Reply-To: <86d19xhdv0.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-06/txt/msg00595.txt.bz2 Yao Qi wrote: > Wei-min Pan writes: > > >>> The new file sparc64-adi-tdep.c should be merged into the existing >>> sparc64-tdep.c. The file name schema in GDB is ARCH-OSABI-tdep.c. >>> Since adi is a new hardware feature rather than an OSABI, it should be >>> put in sparc64-tdep.c >>> >>> >> Originally it was part of sparc64-tdep.c. But our engineer thought >> it's cleaner to make it a >> separate source file. Being new to the gnu world, I believe following >> the file name schema >> is the way to go. Thanks. >> >> > > That is the current file name convention we have to follow, however, I > personally prefer putting them into separated files. Let me post a mail > to ask this. > Thanks for bringing up and taking care of this matter. I will create sparc64-tdep-adi.c for SPARC ADI support. >>> You can't access /proc in *-tdep.c file, because it is also compiled for >>> cross-debugger. The rule in general is to move it to sparc64-linux-nat.c. >>> >>> >> It's nice to know. Will look into it. BTW is there any document that >> specifies/defines these rules for >> *-tdep.c and *-nat.c files? >> > > I was puzzled by this for several years when I started on GDB :) The > most relevant one is > https://sourceware.org/gdb/wiki/Internals%20Native-Debugging In short, > anything required in native debugging (gdb and program are running on > the same machine) should be put in *-nat.c. The rest of things related > to this arch should be put into *-tdep.c. Note some ports have > *-linux-nat.c and *-linux-tdep.c, the former is about anything required > in Linux native debugging (gdb and the program is running on the same Linux > machine), while the latter is about debugging a program running on Linux > of that arch. > I'm glad that I wasn't the only one who struggled to grasp the concept :) Thanks for the clarification (also Pedro's).