Re: [Crash-utility] [PATCH] bug on get_be_long() and improvement of bt

----- "Hu Tao" <hutao(a)cn.fujitsu.com&gt; wrote: > Hi Dave, > > These are updated patches tested with SMP system and panic task. > > When testing a x86 guest, I found another bug about reading cpu > registers from dumpfile. Qemu simulated system is x86_64 > (qemu-system-x86_64), guest OS is x86. When crash reads cpu registers > from dumpfile, it uses cpu_load_32(), this will read gp registers by > get_be_long(fp, 32), that is, treate them as 32bits. But in fact, > qemu-system-x86_64 saves 64bits for each of them(although guest OS > uses only lower 32 bits). As a result, crash gets wrong cpu gp > register values. As I understand it, you're running a 32-bit guest on a 64-bit host.

If you were to read 64-bit register values instead of 32-bit register values, wouldn't that cause the file offsets of the subsequent get_xxx() calls in cpu_load() to read from the wrong file offsets? And then that would leave the ending file offset incorrect, such that the qemu_load() loop would fail to find the next device? In other words, the cpu_load() function, which is used for both 32-bit and 64-bit guests, must be reading the correct amount of data from the "cpu" device, or else qemu_load() would fail to find the next device in the next location in the dumpfile.

> Is there any way we can know from dumpfile that these gp > registers(and those similar registers) are 32bits or 64bits? I don't know. If what you say is true, when would those registers ever be 32-bit values?