From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29767 invoked by alias); 12 Jul 2017 00:36:43 -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 29750 invoked by uid 89); 12 Jul 2017 00:36:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=BAYES_00,GIT_PATCH_2,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=H*MI:default, H*M:default, Hx-languages-length:1812 X-HELO: aserp1040.oracle.com Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Jul 2017 00:36:41 +0000 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6C0aZlg015069 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 12 Jul 2017 00:36:36 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v6C0aZM0024976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 12 Jul 2017 00:36:35 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6C0aZp2012450; Wed, 12 Jul 2017 00:36:35 GMT MIME-Version: 1.0 Message-ID: <98885f9a-7c06-4ab5-b9a2-342277839cc4@default> Date: Wed, 12 Jul 2017 00:36:00 -0000 From: Weimin Pan To: Cc: , Subject: Re: [PING] [PATCH v3] gdb: ADI support Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SW-Source: 2017-07/txt/msg00101.txt.bz2 Simply using target_fileio_xxx routines to replace their corresponding open/pread64/pwrite64/close calls, as you suggested, does solve the cross-referencing problem.=20 The cross gdb build for all targets was then retried and=20 was successful. Thanks much. ----- Original Message ----- From: palves@redhat.com To: weimin.pan@oracle.com, qiyaoltc@gmail.com Cc: gdb-patches@sourceware.org Sent: Tuesday, July 11, 2017 5:21:26 AM GMT -08:00 US/Canada Pacific Subject: Re: [PING] [PATCH v3] gdb: ADI support On 07/11/2017 03:56 AM, Wei-min Pan wrote: > With your comments like: > * You can't access /proc in *-tdep.c file, because it is also compiled f= or > cross-debugger (from previous review); > * We can't include "nat.h" in "tdep.c"; > * Calling pread64 in -tdep.c makes few sense to me. If you only want to > support native debugging, move them to -nat.c file. >=20 > I now believe that the ADI support should be in sparc6 4-linux-nat.c, > not sparc64-tdep.c. Doing so also makes cross gdb build a non-issue. Please don't leave remote debugging out of the design. I.e., remote debugging against gdbserver. You were reading some /proc files with target_fileio, like: snprintf (filename, sizeof filename, "/proc/%d/adi/maps", pid); char *data =3D target_fileio_read_stralloc (NULL, filename); and that should work against gdbserver. (It'll read the remote target file when remote debugging.) So one way would be to replace open/pread64/close etc calls with calls to corresponding target_fileio_xxx routines. Alternatively (or in addition) defining new "enum target_object" objects, and then using the target_xfer_partial interface may make sense. (I really haven't studied the code in any detail to tell, but it should be a useful pointer, regardless.) Thanks, Pedro Alves