From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23282 invoked by alias); 16 Oct 2013 12:08:34 -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 23268 invoked by uid 89); 16 Oct 2013 12:08:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 16 Oct 2013 12:08:33 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r9GC8QiK014462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Oct 2013 08:08:27 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r9GC8OAb026955; Wed, 16 Oct 2013 08:08:25 -0400 Message-ID: <525E81B8.90003@redhat.com> Date: Wed, 16 Oct 2013 12:08:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yao Qi CC: Doug Evans , "Abid, Hafiz" , "gdb-patches@sourceware.org" , "Mirza, Taimoor" Subject: Re: [patch] Disassembly improvements References: <525C02E5.2060601@redhat.com> <21085.59640.697075.435874@ruffy.mtv.corp.google.com> <525E4596.70503@codesourcery.com> In-Reply-To: <525E4596.70503@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-10/txt/msg00481.txt.bz2 On 10/16/2013 08:51 AM, Yao Qi wrote: > On 10/16/2013 09:16 AM, Doug Evans wrote: >> > If I were to try one, I think it would be along the lines of >> > a new TARGET_OBJECT_DISASM_MEMORY, and somehow pass more info down >> > the target_xfer interface so that the the core memory reading code >> > handles the caching. Probably, that'd be done with a new pair of >> > 'begin/end code caching' functions that would be called at the >> > appropriate places. The new code in dis_asm_read_memory would >> > then be pushed to target.c, close to where stack cache is handled. >> >> How hard would it be to do that now? > > AFAICS, it is not hard. We've already had TARGET_OBJECT_STACK_MEMORY, > so it is straightforward to add TARGET_OBJECT_CODE_MEMORY, and disas and > skip_prologue can use it. Are you going to give it a try? That'd be great. Yeah, adding the new target object part is straightforward. What may not be, is either adjusting the dcache.c to the specifics of disassembly, and range limiting, and making sure the cache is bounded correctly, and flushed at the appropriate times. It's one of those "must try it to tell" things, I think. -- Pedro Alves