[Crash-utility] [PATCH] bug on get_be_long() and improvement of bt
Dave Anderson
anderson at redhat.com
Tue Oct 19 13:06:33 UTC 2010
----- "Hu Tao" <hutao at cn.fujitsu.com> 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?
Dave
More information about the Crash-utility
mailing list