Hi,
I am looking at the source code of QEMU, and there are some mystery to
me: some functions are not defined anywhere.
For example, functions like compute_all_incb() and compute_c_incl() in
target-i386/op.c are never defined anywhere.
So how the compilation process generates these functions?
On Tue, Oct 16, 2007 at 05:28:24PM +0900, Jun Koi wrote:
For example, functions like compute_all_incb() and compute_c_incl() in
target-i386/op.c are never defined anywhere.
compute_all_inc* are defined in ops_template.h:~171. You'll notice that
ops_template.h is included four times from op.c.
On Mon, Oct 15, 2007 at 06:15:29PM -0700, Jeff Carr wrote:
For those that might not be familiar with SIGWINCH, supporting it
would allow qemu -nographic to tell when the terminal is a different
size than 80x24.
That would need support on the remote side (the getty) as well as on the
terminal
Hi,
On Tue, 16 Oct 2007, Stuart Brady wrote:
On Tue, Oct 16, 2007 at 05:28:24PM +0900, Jun Koi wrote:
For example, functions like compute_all_incb() and compute_c_incl() in
target-i386/op.c are never defined anywhere.
compute_all_inc* are defined in ops_template.h:~171. You'll notice
On 10/15/07 19:32, Paul Brook wrote:
qemu emulates a real machine. Signals are an operating system concept, so your
question makes no sense. Configure your guest OS exactly the same way you
would a real machine with a serial console.
OK. I thought there might be a way.
The linux-user code
Hello,
I have digged further my problem of keyboard problem when the mouse is
activated
using qemu (i.e. dummy char present in the keyboard buffer), and can say that
this patch solves completely the problem:
$ diff -urp qemu-0.9.0-init qemu-0.9.0
diff -urp
On Mon, 2007-10-15 at 23:42 +0100, Paul Brook wrote:
VLE targets (x86, m68k) can translate almost a full page of instructions,
and a page boundary can be anywhere within that block. Once we've spanned
multiple pages there's not point stopping translation immediately. We may
as well
Jeff Carr schrieb:
On 10/15/07 19:32, Paul Brook wrote:
qemu emulates a real machine. Signals are an operating system
concept, so your
question makes no sense. Configure your guest OS exactly the same way
you
would a real machine with a serial console.
OK. I thought there might be a way.
I failed to run Mips target test image on my amd64 machine and I now
found the reason of the bug:
the kernel loader code used in hw/mips_r4k.c and hw/mips_malta.c
implicitelly assumes that the ram_addr_t is 32 bits long.
Unfortunatelly, on 64 bits hosts, this won't be the case and the kernel
load
I think your question is quite reasonable. Imagine a Linux host
running X Windows and a terminal like xterm or kconsole.
Then run a program like top or less in this terminal.
When a user changes the size of the console window, top, less
and other console applications get notified of this
Well, we got the same behavior on PowerPC. What I was thinking of is
that if we fix the VLE problems, the fix, if done in a proper way, could
also allow benefit to RISC targets. What I don't know is; would we
really have a benefit not stopping translation on page boundaries ?
For VLE
Well, we got the same behavior on PowerPC. What I was thinking of is
that if we fix the VLE problems, the fix, if done in a proper way, could
also allow benefit to RISC targets. What I don't know is; would we
really have a benefit not stopping translation on page boundaries ?
[ I meant to say
On Tue, 2007-10-16 at 23:00 +0100, Paul Brook wrote:
Well, we got the same behavior on PowerPC. What I was thinking of is
that if we fix the VLE problems, the fix, if done in a proper way, could
also allow benefit to RISC targets. What I don't know is; would we
really have a benefit not
I suspect the best solution is to backtrack (remove the generated ops)
after decoding the insn if we discover we've passed a page boundary. The
ld*_code routines can simply return garbage (e.g. zero) if the read is
not on the first page.
The incorrect returned value may be target
14 matches
Mail list logo
