From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5281 invoked by alias); 14 Oct 2013 14:42:51 -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 5267 invoked by uid 89); 14 Oct 2013 14:42:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 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; Mon, 14 Oct 2013 14:42:50 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r9EEglXk003280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Oct 2013 10:42:48 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r9EEgkmG027770; Mon, 14 Oct 2013 10:42:46 -0400 Message-ID: <525C02E5.2060601@redhat.com> Date: Mon, 14 Oct 2013 14:42: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: Doug Evans CC: "Abid, Hafiz" , "gdb-patches@sourceware.org" , "Mirza, Taimoor" Subject: Re: [patch] Disassembly improvements References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-10/txt/msg00434.txt.bz2 On 10/11/2013 10:34 PM, Doug Evans wrote: > This is a specific fix to a general problem. I don't know that this is a general problem. It may look like one, but it's not super clear to me. Yes, we might have a similar problem caused by lots of tiny reads from the target during prologue analysis. But the approach there might be different from the right approach for disassembly, or we could also come to the conclusion the problem there is not exactly the same. > Question: How much more of the general problem can we fix without > having a fix baked into the disassembler? The disassembly use case is one where GDB is being told by the user "treat this range of addresses that I'll be reading sequencially, as code". If that happens to trip on some memory mapped registers or some such, then it's garbage-in, garbage-out, it was the user's fault. As I mentioned in , I'd rather we analyze the use cases independently (I'm not saying they're not the same). If we find commonalities, we can certainly factor things out and come up with more general abstractions then. 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. The main point there should be consensus on, is that a caching scheme is a better solution for the disassembly use case, than trusting read only sessions is, for the later doesn't have the problem with self-modifying code, and, in addition, it also speeds up disassembling when there is _no_ corresponding binary/'text section'. I don't think there's any need to hold considering this quite localized fix for slow disassembling as is while we investigate other use cases. IOW, we should let the code start small, and grow/evolve from there. -- Pedro Alves