-d option outs wrong info about sections For example, after run ./qemu-i386 -d in_asm /bin/ls from 0.14.0 release, I received this qemu.log file: $ cat /tmp/qemu.log | grep -A7 guest Relocating guest address space from 0x08048000 to 0x8048000 guest_base 0x0 start end size prot 00048000-0005f000 00017000 r-x 0005f000-00069000 0000a000 rw- 00040000-00041000 00001000 --- 00041000-00041800 00000800 rw- 00041800-0005d800 0001c000 r-x 0005d800-0005f800 00002000 rw- But such command in 0.12.5 release outs this: $ cat /tmp/qemu.log | grep -A7 guest guest_base 0x0 start end size prot 00f38000-00f39000 00001000 --- 08048000-0805f000 00017000 r-x 0805f000-08061000 00002000 rw- 40000000-40080000 00080000 rw- 40080000-40081000 00001000 --- 40081000-4009d000 0001c000 r-x It looks correct. I received such differences and with qemu-microblaze. After comparing 0.12.5 and 0.14.0 releases I found this differences in exec.c: in 0.12.5: end = (i << (32 - L1_BITS)) | (j << TARGET_PAGE_BITS); in 0.14.0: int rc = walk_memory_regions_1(&data, (abi_ulong)i << V_L1_SHIFT, V_L1_SHIFT in my case is 10, but 32 - L1_BITS is 22 I make this changes: $ diff -up qemu-0.14.0/exec.c exec.c --- qemu-0.14.0/exec.c 2011-04-08 17:26:00.524464002 +0400 +++ exec.c 2011-04-08 17:26:09.800464003 +0400 @@ -2340,7 +2340,7 @@ int walk_memory_regions(void *priv, walk data.prot = 0; for (i = 0; i < V_L1_SIZE; i++) { - int rc = walk_memory_regions_1(&data, (abi_ulong)i << V_L1_SHIFT, + int rc = walk_memory_regions_1(&data, (abi_ulong)i << (V_L1_SHIFT + TARGET_PAGE_BITS), V_L1_SHIFT / L2_BITS - 1, l1_map + i); if (rc != 0) { return rc; After this outputs looks correct. I don't know code base good, and think what may to do more general corrections. Host system: linux i386 Hi, Thanks for reporting this issue, and the investigation. I don't really understand the rationale for the change, so I can't help much. This change appears to be from 5cd2c5b6ad75c46d40118ac67c0c09d4e7930a65. I think input from Richard Henderson (the author of the change) would be very useful. Brad Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? [Expired for QEMU because there has been no activity for 60 days.]