From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24767 invoked by alias); 23 Feb 2012 06:56:53 -0000 Received: (qmail 24758 invoked by uid 22791); 23 Feb 2012 06:56:52 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 23 Feb 2012 06:56:38 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1S0SbV-0004D2-6Q from Yao_Qi@mentor.com ; Wed, 22 Feb 2012 22:56:37 -0800 Received: from SVR-ORW-FEM-03.mgc.mentorg.com ([147.34.97.39]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 22:56:34 -0800 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.1.289.1; Wed, 22 Feb 2012 22:56:35 -0800 Message-ID: <4F45E2F8.7090606@codesourcery.com> Date: Thu, 23 Feb 2012 07:51:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20120130 Thunderbird/10.0 MIME-Version: 1.0 To: Pedro Alves CC: 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> In-Reply-To: <4F3545A2.9020901@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-IsSubscribed: yes 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/msg00499.txt.bz2 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? > 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. -- Yao (齐尧)