From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23171 invoked by alias); 4 May 2010 00:32:03 -0000 Received: (qmail 23161 invoked by uid 22791); 4 May 2010 00:32:02 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 May 2010 00:31:59 +0000 Received: (qmail 1688 invoked from network); 4 May 2010 00:31:57 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 4 May 2010 00:31:57 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFC] New targets remote-rx and extended-remote-rx Date: Tue, 04 May 2010 00:32:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-20-generic; KDE/4.3.2; x86_64; ; ) Cc: Kevin Buettner References: <20100430144218.182aa18b@redhat.com> <201004302335.44097.pedro@codesourcery.com> <20100503153029.34287dfe@redhat.com> In-Reply-To: <20100503153029.34287dfe@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005040131.53858.pedro@codesourcery.com> 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: 2010-05/txt/msg00060.txt.bz2 On Monday 03 May 2010 23:30:29, Kevin Buettner wrote: > On Fri, 30 Apr 2010 23:35:44 +0100 > Pedro Alves wrote: > > I'm not sure I grasped it enough to understand > > if this could benefit from a TARGET_OBJECT_MEMORY_CODE vs > > TARGET_OBJECT_MEMORY_DATA request distinction, instead of just > > calling everything TARGET_OBJECT_MEMORY? That is switch > > the swapping decision to the transfer intent, not to where > > the code is in memory. > > I'll have to think about this. Doesn't sound unreasonable though. > > > For example, what should happen > > if I build a buffer of executable code in memory at runtime, > > and I want to disassemble it with GDB? I'll build the memory > > buffer, with a layout as the compiler puts things in .text, > > but the code will not be in .text, yet, don't I want for > > GDB to read it in execute order, not memory order? > > E.g, a just-in-time (JIT) compiler? Yes, you'd want GDB to convert > dynamically compiled code from memory order to execute order. Yes, that's one example, although there are many more use cases beyond a full fledged compiler. Just staying in gdb land, think of things like debugging the displaced stepping scratch pad (when you add support for non-stop mode you'll want to debug this, probably). Another example, debugging fast tracepoints support for RX. In the latter, we patch the code stream with a jump into small trampoline routine built at runtime in the inferior's memory. Just copying a piece of .text code into a data buffer, and trying to disassemble it is another example. The more I think of this, the more it seems that it's the thought/intent that counts. -- Pedro Alves