I was surprised that my user-mode applications ran successfully under
qemu-ppc64 2.10.1
running on Linux on x86_64, but crashed when run directly under Linux on 64-bit
PowerPC.
Investigation showed that qemu-ppc64 does not emulate system calls faithfully.
On real Linux on PowerPC64, a system ca
... this one is even smaller. Plus it uses the familiar strlen() function:
size_t strnlen(const char *string, size_t max_count)
{
return strlen(string) < max_count ? strlen(string) : max_count;
}
Please do not use that implementation.
The major goal of strnlen is to avoid looking beyond
"qemu-ppc -g 1234 foo" emulating the 32-bit PowerPC instruction 0x7c88
("tweq r0,r0") terminates with "fatal: Tried to call a TRAP".
Instead, when co-operating with gdbserver (-g ) then qemu-ppc
should generate a SIGTRAP, just like real execution under gdb.
The "tweq r0,r0" and others are use
I don't really know why we use 0xf700 as our
reserved_va value here, though. Alex, you added that
years ago, can you remember why you used that value?
IIRC I wanted to map the full 32 bits of address space possibly in use by a
32bit application, but leave some room for something, but I don'
Thanks for your reply, Peter. [I fixed my typo in the Subject: field of the
header.]
[Moving here from https://bugzilla.redhat.com/show_bug.cgi?id=1493304 ]
qemu-arm from qemu-user-2.10.0-1.fc27.x86_64 (thus emulating 32-bit ARM on
x86_64)
generates SIGSEGV when code modifies a never-previou
[Moving here from https://bugzilla.redhat.com/show_bug.cgi?id=1493304 ]
qemu-arm from qemu-user-2.10.0-1.fc27.x86_64 (thus emulating 32-bit ARM on
x86_64)
generates SIGSEGV when code modifies a never-previously executed instruction
that is on a writable page and is 848 bytes ahead of pc.
A real
ild process. Nobody has to guess or to "snoop" the memory
bus in order to discover that the instruction stream is being modified.
Instead, there is direct notification of what is happening. If nothing
else, then under CONFIG_QEMU the implementation of sys_ptrace()
must notify the emul
.
--- a/qemu-0.9.0/target-mips/helper.c 2007-05-05 15:39:21.0 -0700
+++ b/qemu-0.9.0/target-mips/helper.c 2007-05-07 13:24:50.0 -0700
@@ -358,6 +358,7 @@
goto set_EPC;
case EXCP_BREAK:
cause = 9;
+ tlb_flush_page(env, env->PC);
goto set_EPC;
case EXCP_RI:
cause = 10;
--
John Reiser, [EMAIL PROTECTED]
ted system.]
Please suggest how to find and fix this bug?
(It's hard to remember to avoid single-stepping 'lw'.)
--
John Reiser, [EMAIL PROTECTED]
(perhaps triple-fault?) and shuts down.
It would be nice if qemu emulation detected such a situation,
then issued an informative message, in addition to
looping forever as an "emulation" of hardware shutdown.
--
John Reiser, [EMAIL PROTECTED]
_
Note that the Open-Firmware frame-buffer support is broken in many 2.6
kernels (I mean on real Macs)
How so ?
Well, in Fedora Core 4 test 3 (kernels 2.6.11.* and 2.6.12-rc*):
video switching at boot from yaboot with Open Firmware to Tux with
scrolling VGA text is problematic, and switching v
the relocation directives for access to a few static 'const'
arrays) is easy.
--
John Reiser, [EMAIL PROTECTED]
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
12 matches
Mail list logo
