From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33512) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zyql1-0004Vx-6g for qemu-devel@nongnu.org; Tue, 17 Nov 2015 19:37:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zyqky-0005Jf-00 for qemu-devel@nongnu.org; Tue, 17 Nov 2015 19:37:55 -0500 Received: from relay1.mentorg.com ([192.94.38.131]:44870) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zyqkx-0005JV-Pz for qemu-devel@nongnu.org; Tue, 17 Nov 2015 19:37:51 -0500 References: <1447290598-13069-1-git-send-email-hollis_blanchard@mentor.com> <1447290598-13069-2-git-send-email-hollis_blanchard@mentor.com> <20151113102313.GG6650@stefanha-x1.localdomain> From: Hollis Blanchard Message-ID: <564BC85C.2090106@mentor.com> Date: Tue, 17 Nov 2015 16:37:48 -0800 MIME-Version: 1.0 In-Reply-To: <20151113102313.GG6650@stefanha-x1.localdomain> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] trace: show MemoryRegion name, not address List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org On 11/13/2015 02:23 AM, Stefan Hajnoczi wrote: > On Wed, Nov 11, 2015 at 05:09:58PM -0800, Hollis Blanchard wrote: >> Recording the MemoryRegion pointers isn't helpful, especially since no trace >> data allows us to correlate those pointers to devices. Instead, record the >> MemoryRegion name. >> >> Signed-off-by: Hollis Blanchard >> --- >> memory.c | 12 ++++++------ >> trace-events | 4 ++-- >> 2 files changed, 8 insertions(+), 8 deletions(-) >> >> diff --git a/memory.c b/memory.c >> index c435c88..9bd4c31 100644 >> --- a/memory.c >> +++ b/memory.c >> @@ -381,7 +381,7 @@ static MemTxResult memory_region_oldmmio_read_accessor(MemoryRegion *mr, >> uint64_t tmp; >> >> tmp = mr->ops->old_mmio.read[ctz32(size)](mr->opaque, addr); >> - trace_memory_region_ops_read(mr, addr, tmp, size); >> + trace_memory_region_ops_read(mr->name, addr, tmp, size); > mr->name may be NULL. There is a memory_region_name() function that > always produces a real string. Perhaps it's best to use it. Using memory_region_name() yields this: ** ERROR **: file qom/object.c: line 1427 (object_get_canonical_path_component): assertion failed: (obj->parent != NULL) aborting... The offending MemoryRegion seems to be a subpage one, which has no name. I can tell because ops contains links to subpage_read() and subpage_write(). "info mtree" uses memory_region_name() and works fine, but perhaps that's because it only goes 2 levels deep? Hollis Blanchard Mentor Graphics Emulation Division