From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2406 invoked by alias); 27 Nov 2013 13:49:57 -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 2396 invoked by uid 89); 27 Nov 2013 13:49:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 27 Nov 2013 13:49:55 +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 rARDnjQT023937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Nov 2013 08:49:45 -0500 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 rARDnhf1002411; Wed, 27 Nov 2013 08:49:44 -0500 Message-ID: <5295F877.3060004@redhat.com> Date: Wed, 27 Nov 2013 15:27: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: gdb-patches@sourceware.org Subject: Re: [PATCH] Delegate to target_ops->beneath to read cache lines References: <1385554824-7159-1-git-send-email-yao@codesourcery.com> In-Reply-To: <1385554824-7159-1-git-send-email-yao@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-11/txt/msg00842.txt.bz2 On 11/27/2013 12:20 PM, Yao Qi wrote: > GDB on x86_64-linux is unable to disassemble on core-file target. > > $ ./gdb ./testsuite/gdb.base/corefile > (gdb) core-file ./testsuite/gdb.base/corefile.core > (gdb) disassemble main > Dump of assembler code for function main: > 0x0000000000400976 <+0>: Cannot access memory at address 0x400976 > > However, it works if we turn code-cache off. > > (gdb) set code-cache off > (gdb) disassemble main,+4 > Dump of assembler code from 0x400976 to 0x40097a: > 0x0000000000400976 : push %rbp > 0x0000000000400977 : mov %rsp,%rbp > End of assembler dump. > > When code-cache is off, GDB will iterate target_ops from top and call > to_xfer_partial. When current_target is "core", it will call > to_xfer_partial of target "exec", which reads the contents for > disassemble. However, dcache doesn't have such mechanism, and that is > the cause for the error. This points out that we end up caching core and exec code, which isn't really necessary. We could limit it to has_all_memory targets, I think. Not sure if that'd complicate things. > This patch adds something similar in dcache_read_line to go through > target_ops from top to bottom, and call to_xfer_partial. > The original code uses TARGET_OBJECT_RAW_MEMORY, which is replaced > by TARGET_OBJECT_MEMORY in target_xfer_partial, > > enum target_object raw_object = object; > > /* If this is a raw memory transfer, request the normal > memory object from other layers. */ > if (raw_object == TARGET_OBJECT_RAW_MEMORY) > raw_object = TARGET_OBJECT_MEMORY; > > so we can use TARGET_OBJECT_MEMORY here. Regression tested on > x86_64-linux. The dcache is the sole user of TARGET_OBJECT_RAW_MEMORY. This shows that if we want to code from lower targets too, then this sole user also wants to do the top to bottom delegation that memory_xfer_partial_1 does. So this can all be done within target.c. Factor out the memory_xfer_partial_1 top to bottom memory read code to a separate raw_memory_xfer_partial function (despite the name, it'd request TARGET_OBJECT_MEMORY from the targets), and make target_xfer_partial call that for TARGET_OBJECT_RAW_MEMORY: LONGEST target_xfer_partial (struct target_ops *ops, enum target_object object, const char *annex, void *readbuf, const void *writebuf, ULONGEST offset, LONGEST len) { LONGEST retval; /* If this is a memory transfer, let the memory-specific code have a look at it instead. Memory transfers are more complicated. */ if (object == TARGET_OBJECT_MEMORY || object == TARGET_OBJECT_STACK_MEMORY || object == TARGET_OBJECT_CODE_MEMORY) retval = memory_xfer_partial (ops, object, readbuf, writebuf, offset, len); else if (object == TARGET_OBJECT_RAW_MEMORY) { /* Request the normal memory object from other layers. */ retval = raw_memory_xfer_partial (ops, readbuf, writebuf, offset, len); } else { retval = ops->to_xfer_partial (ops, raw_object, annex, readbuf, writebuf, offset, len); } Then dcache.c doesn't need to change, and doesn't need to inline that top to bottom dance. -- Pedro Alves