From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4813 invoked by alias); 23 Feb 2012 18:24:27 -0000 Received: (qmail 4791 invoked by uid 22791); 23 Feb 2012 18:24:26 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 23 Feb 2012 18:24:14 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1NIO9qV011914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Feb 2012 13:24:09 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q1NIO7QE019942; Thu, 23 Feb 2012 13:24:09 -0500 Message-ID: <4F468447.5060906@redhat.com> Date: Thu, 23 Feb 2012 19:50:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: Yao Qi CC: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [patch 5/8] Doc for agent References: <4F1D55D7.7030506@codesourcery.com> <4F1D678B.2040705@codesourcery.com> <4F34248A.8070706@redhat.com> <4F351BC1.9080601@codesourcery.com> <4F353146.3020504@redhat.com> <4F354343.3060302@codesourcery.com> <4F3545A2.9020901@redhat.com> <4F45E2F8.7090606@codesourcery.com> In-Reply-To: <4F45E2F8.7090606@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2012-02/txt/msg00513.txt.bz2 On 02/23/2012 06:55 AM, Yao Qi wrote: > On 02/11/2012 12:28 AM, Pedro Alves wrote: >>>> The reasons for this kind of design are, >>>> >>>> #1. agent, inferior and debugger (GDB or GDBserver) are running >>>> on the same machine, so protocol doesn't to have to handle machine >>>> difference, such as endianess, word size, etc. Binary copy should >>>> work fine. >> Nope, that's not true at all. Several architectures can run in >> different modes (x86 32-bit/64-bit; arm/thumbx big/little/mixed; mips; ppc, etc.). >> Several architectures have more than one ABI. We can have e.g., a 64-bit >> gdbserver controlling a 32-bit process on x86. You can have a gdbserver controlling >> an inferior that's running a different endianness on some machines. >> > > I agree that the process of GDB/GDBserver and process of inferior have > differences on ABI, word-size, except endianess. I can't find an > example that two processes on the same machine have different endianess. > I google'ed a while, and find some processors such as ARM, PowerPC, and > Itanium have such capability to change endian mode on runtime, but seems > not widely used. Do we need to consider this case here? Maybe not used much presently. But I don't see how that makes a difference. It's best for GDBserver to not assume much from the inferior. >> The current IPA has the limitation that fast tracepoints only work if the >> inferior has the same arch/abi as gdbserver. If we're adding a new IPC, >> and an IPA v2, let's not repeat the mistake. >> > > Pedro, thanks for your input. I'll post the agent protocol draft later. -- Pedro Alves