From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59054) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1UNi-0007yT-SK for qemu-devel@nongnu.org; Wed, 25 Nov 2015 02:20:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1UNf-0001hp-Gx for qemu-devel@nongnu.org; Wed, 25 Nov 2015 02:20:46 -0500 Received: from mail-pa0-x22e.google.com ([2607:f8b0:400e:c03::22e]:36107) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1UNf-0001h1-Ad for qemu-devel@nongnu.org; Wed, 25 Nov 2015 02:20:43 -0500 Received: by pacdm15 with SMTP id dm15so48728239pac.3 for ; Tue, 24 Nov 2015 23:20:42 -0800 (PST) Date: Wed, 25 Nov 2015 15:20:38 +0800 From: Stefan Hajnoczi Message-ID: <20151125072038.GA7357@stefanha-x1.localdomain> 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> <564BC85C.2090106@mentor.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: <564BC85C.2090106@mentor.com> 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: Hollis Blanchard Cc: qemu-devel@nongnu.org --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 17, 2015 at 04:37:48PM -0800, Hollis Blanchard wrote: > 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_acces= sor(MemoryRegion *mr, > >> uint64_t tmp; > >> tmp =3D 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. >=20 > Using memory_region_name() yields this: > ** ERROR **: file qom/object.c: line 1427 > (object_get_canonical_path_component): assertion failed: (obj->parent !=3D > NULL) > aborting... >=20 > 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(). >=20 > "info mtree" uses memory_region_name() and works fine, but perhaps that's > because it only goes 2 levels deep? I'm not very familiar with the memory API so I'm afraid I don't know the best solution. My concern about a NULL string pointer is that some operating systems ship a libc that segfaults instead of snprintf(..., "%s", NULL) to "(null)". So the stderr trace backend could crash on those operating systems. Stefan --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWVWFGAAoJEJykq7OBq3PIDvsH/1dgPGEWHKuTEV7rELnqhwWR e2C+VgSNukTZF7tbQcLf4xUwPBalkF06XRHPjv9w+HjQ7ICre2TgE5XCmRVOhli2 n+eP18YSz/mAU+SNMjH/XVMxz4/vW370vyVPvo/Y9gXNteAuT2JRNnHESw0aF+xr Sjn9Gpvz/0S8fAj+QiuhoYKshaZaceBxqNDLNDd6+MrG0TBC6hKz2cFUSyzn7n3n KuP6sd1sJ9TNZ5kQRqhr2tOnFKWql29JkTfv78rhf0ZdJ+k9eMAhEkLl5NxyAFkc ZpHrgwygAX8S2GU0JAH/WLBxs6Ly+6LILKI9E6jmSFYi0sCtxnmhde1iqHj/LRM= =zbFv -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J--