[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [Bug 1810545] [NEW] [alpha] Strange exception address repor
From: |
Stefan Ring |
Subject: |
[Qemu-devel] [Bug 1810545] [NEW] [alpha] Strange exception address reported |
Date: |
Fri, 04 Jan 2019 18:21:31 -0000 |
Public bug reported:
For some reason the SIGILL handler receives a different address under
qemu than it used to on real hardware. I don't know specifics about the
hardware used back then – it was some sort of 21264a somewhere between
600-800 MHz –, and I cannot say anything about the kernel as well, but I
know that it delivered the faulting address +4, while under qemu it
receives +8. I know because CACAO, an early Java JIT compiler extracts
the address from the SIGILL handler and inspects the code at the
faulting site, and it has substracted 4 from the handler address since
the dawn of time, and this used to produce the desired result on the
Alpha hardware. It actually ran on two different Alpha machines over the
years, and both behaved identically.
The handler looks like this:
void handler_sigill(int sig, siginfo_t *siginfo, void *_p)
{
uintptr_t trap_address = (uintptr_t) (((ucontext_t*) _p)->uc_mcontext.sc_pc)
- 4;
}
(paraphrasing, the actual code is here: https://bitbucket.org/cacaovm
/cacao-
staging/src/c8d3fbab864c3243f97629fcfa8d84ba71f38157/src/vm/jit/alpha/linux
/md-os.cpp?at=default&fileviewer=file-view-default#md-os.cpp-65)
I don't know much about the qemu source code and cannot say where this
is coming from at first glance. The gen_invalid function uses pc_next,
which sounds like the next instruction, not the next-to-next ;). In
theory it could actually be the kernel's fault, although I consider this
unlikely.
This is qemu-system-alpha with apparently the last Debian which existed
for Alpha (lenny). The kernel is 2.6.26-2-alpha-generic (Debian
2.6.26-29). Observed with qemu git 1b3e80082b, but I guess it is the
same with any version.
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1810545
Title:
[alpha] Strange exception address reported
Status in QEMU:
New
Bug description:
For some reason the SIGILL handler receives a different address under
qemu than it used to on real hardware. I don't know specifics about
the hardware used back then – it was some sort of 21264a somewhere
between 600-800 MHz –, and I cannot say anything about the kernel as
well, but I know that it delivered the faulting address +4, while
under qemu it receives +8. I know because CACAO, an early Java JIT
compiler extracts the address from the SIGILL handler and inspects the
code at the faulting site, and it has substracted 4 from the handler
address since the dawn of time, and this used to produce the desired
result on the Alpha hardware. It actually ran on two different Alpha
machines over the years, and both behaved identically.
The handler looks like this:
void handler_sigill(int sig, siginfo_t *siginfo, void *_p)
{
uintptr_t trap_address = (uintptr_t) (((ucontext_t*)
_p)->uc_mcontext.sc_pc) - 4;
}
(paraphrasing, the actual code is here: https://bitbucket.org/cacaovm
/cacao-
staging/src/c8d3fbab864c3243f97629fcfa8d84ba71f38157/src/vm/jit/alpha/linux
/md-os.cpp?at=default&fileviewer=file-view-default#md-os.cpp-65)
I don't know much about the qemu source code and cannot say where this
is coming from at first glance. The gen_invalid function uses pc_next,
which sounds like the next instruction, not the next-to-next ;). In
theory it could actually be the kernel's fault, although I consider
this unlikely.
This is qemu-system-alpha with apparently the last Debian which
existed for Alpha (lenny). The kernel is 2.6.26-2-alpha-generic
(Debian 2.6.26-29). Observed with qemu git 1b3e80082b, but I guess it
is the same with any version.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1810545/+subscriptions
- [Qemu-devel] [Bug 1810545] [NEW] [alpha] Strange exception address reported,
Stefan Ring <=