* [Qemu-devel] bug report
@ 2009-01-11 12:07 Artem Kozarezov
0 siblings, 0 replies; 14+ messages in thread
From: Artem Kozarezov @ 2009-01-11 12:07 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 189 bytes --]
FreeBSD 7.1 livefs hangs loading the kernel:
http://qemu-forum.ipi.fi/viewtopic.php?f=14&t=617&p=14188#p14188
I think the problem is easy to repeat, so it's kind of a bug report.
Comments?
[-- Attachment #2: Type: text/html, Size: 302 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Qemu-devel] bug report
@ 2013-10-06 16:55 Peter Cheung
0 siblings, 0 replies; 14+ messages in thread
From: Peter Cheung @ 2013-10-06 16:55 UTC (permalink / raw)
To: qemu-devel@nongnu.org
[-- Attachment #1: Type: text/plain, Size: 296 bytes --]
hi all I found a bug in qemu, when i invoke:
cpu_physical_memory_rw(addr, mem_buf, noOfBytes, 0);
where addr=0xffff0 and noOfBytes=50, qemu will has segmentation fault. I call the cpu_physical_memory_rw right after the qemu is started (haven't run yet) with gdb.
Thanksfrom Peter
[-- Attachment #2: Type: text/html, Size: 740 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Qemu-devel] Bug report
@ 2007-12-17 13:48 Bas Wijnen
2007-12-18 16:52 ` Paul Brook
0 siblings, 1 reply; 14+ messages in thread
From: Bas Wijnen @ 2007-12-17 13:48 UTC (permalink / raw)
To: qemu-devel; +Cc: 419369-forwarded, 418036-forwarded, 426781-forwarded
[-- Attachment #1: Type: text/plain, Size: 2730 bytes --]
Hi,
While writing a kernel and testing it with qemu, I found some bugs in
qemu (and many in my kernel ;-) ). Here's a list of them. They are all
about x86 emulation on x86. Some are a bit old, and since my kernel is
now fixed I can't easily test if they still aren't fixed, though.
- When a protection level 0 process returns with iret to a pl3 process,
and the segment registers (other than cs and ss) are set to values
that shouldn't be usable by pl3, real hardware will hang (if there's
no gpf handler) when they are used. However qemu doesn't seem to have
a problem with it at all.
- Qemu initializes all its memory to 0. Real hardware doesn't seem to
do that. This means that usage of uninitialized memory is very hard
to debug (because 0 is often a good value, while [random] is not, so
the problem can only be seen on real hardware, which makes it hard to
debug).
- The timing of the ports are impossibly fast. When writing a byte to a
serial port and immediately asking if the send buffer is empty, it
says it is. This means that code which only runs when waiting for
data to be transmitted will never get tested in qemu, because it is
never "waiting". The same is at least true for the keyboard, I
suppose for other devices as well.
- The system timer (irq 0) runs on real-time, not on emulated time.
This means that the behaviour of programs may differ between machines,
and that sending a test case to someone else may not work.r
For example, if I write (too) much output to the serial port in the
irq0 handler, the cpu never exits the handler (that is, it reenters
when it's about to exit). However, when redirecting the serial port
output from screen into a file (it's going to stdout), the machine
suddenly does execute programs other than the irq handler.
That's all (so far). I can imagine that it is not always desirable to
emulate these things "right", for example with the timing: it's more
important that the emulated machine behaves properly, for example when
it plays music, than that it is reproducible. However, I think
reproducibility would be a nice feature as well. Perhaps it would be
better to add it via a commandline option.
Thanks,
Bas Wijnen
Ps: Please CC me, I'm not subscribed to the list.
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] Bug report
2007-12-17 13:48 [Qemu-devel] Bug report Bas Wijnen
@ 2007-12-18 16:52 ` Paul Brook
2007-12-19 1:11 ` Bas Wijnen
0 siblings, 1 reply; 14+ messages in thread
From: Paul Brook @ 2007-12-18 16:52 UTC (permalink / raw)
To: qemu-devel
Cc: 426781-forwarded, Bas Wijnen, 419369-forwarded, 418036-forwarded
> - Qemu initializes all its memory to 0. Real hardware doesn't seem to
> do that. This means that usage of uninitialized memory is very hard
> to debug (because 0 is often a good value, while [random] is not, so
> the problem can only be seen on real hardware, which makes it hard to
> debug).
Definitely not a bug. I'm fairly sure I've seen real machines that zero memory
on reset. If you want random data if should be fairly trivial to achieve this
in your OS loader.
> - The timing of the ports are impossibly fast.
> - The system timer (irq 0) runs on real-time, not on emulated time.
Qemu is not cycle accurate, so any notion of "emulated time" is completely
arbitrary. Currently qemu is also fairly non-deterministic.
The rate at which it executes instructions may vary greatly. It's not
uncommon for the CPU to stall for several ms, and executing the same code
sequence multiple times may take vastly different amounts of time
This is often true of modern hardware, though generally to a lesser extent.
There are many things that can stall execution, e.g. frequency scaling,
thermal throttling, cache or TLB interactions, DRAM refresh cycles, external
bus masters, etc. You have to lock things down really tightly (and be
extremely careful what hardware you use) if you want hard-realtime
guarantees.
Paul
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] Bug report
2007-12-18 16:52 ` Paul Brook
@ 2007-12-19 1:11 ` Bas Wijnen
0 siblings, 0 replies; 14+ messages in thread
From: Bas Wijnen @ 2007-12-19 1:11 UTC (permalink / raw)
To: qemu-devel; +Cc: 426781-forwarded, 419369-forwarded, 418036-forwarded
[-- Attachment #1: Type: text/plain, Size: 3533 bytes --]
On Tue, Dec 18, 2007 at 04:52:47PM +0000, Paul Brook wrote:
> > - Qemu initializes all its memory to 0. Real hardware doesn't seem to
> > do that. This means that usage of uninitialized memory is very hard
> > to debug (because 0 is often a good value, while [random] is not, so
> > the problem can only be seen on real hardware, which makes it hard to
> > debug).
>
> Definitely not a bug. I'm fairly sure I've seen real machines that
> zero memory on reset.
Not a bug, indeed, but a feature request. :-)
> If you want random data if should be fairly trivial to achieve this in
> your OS loader.
Yes, once I found out that this was about using uninitialized memory it
was easy to trigger. But coming to that conclusion took a long time,
because testing on real hardware requires rebooting and such, and it's
not so easy to get dumps of processor registers. I've streamlined the
process quite a bit, but debugging inside qemu is still much easier than
on a real machine. Therefore anything which makes code run when it
shouldn't is worth making stricter IMO, if only through a commandline
option (--os-test, or something, to switch on all such options
together).
> > - The timing of the ports are impossibly fast.
This is also a thing which makes kernel debugging harder. It's fine if
the timing isn't "correct" as far as I'm concerned. But if it never
reports the ports as busy at all, important parts of kernel code are
never executed, and thus never tested within qemu.
> > - The system timer (irq 0) runs on real-time, not on emulated time.
>
> Qemu is not cycle accurate, so any notion of "emulated time" is completely
> arbitrary. Currently qemu is also fairly non-deterministic.
>
> The rate at which it executes instructions may vary greatly. It's not
> uncommon for the CPU to stall for several ms, and executing the same code
> sequence multiple times may take vastly different amounts of time
I understand, and I don't have a problem with that.
> This is often true of modern hardware, though generally to a lesser extent.
> There are many things that can stall execution, e.g. frequency scaling,
> thermal throttling, cache or TLB interactions, DRAM refresh cycles, external
> bus masters, etc. You have to lock things down really tightly (and be
> extremely careful what hardware you use) if you want hard-realtime
> guarantees.
The cool thing about an emulator is that in theory it would be possible
to have a truely reproducible setup. So I can send you an image file
plus a qemu command line, and you can reproduce whatever I want you to
see (usually a kernel crash, I suppose). On real hardware it is very
well possible that this approach doesn't work: the kernel may behave
completely different on your system. If qemu also behaves different on
your system than on mine, that's not a bug, but it is a missed
opportunity IMO. :-)
Of course if it's a lot of work to implement it, I can understand that
other things have more priority. But I hope to convince you that it
would be a useful feature. :-)
Thanks,
Bas
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Qemu-devel] Bug report
@ 2006-12-03 16:40 Mike Smith
0 siblings, 0 replies; 14+ messages in thread
From: Mike Smith @ 2006-12-03 16:40 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]
I was running Windows 2000 Pro in QEMU (FreeBSD as host) and needed more
disk space. So I created a spare hard drive with this command:
$ qemu-img create -f qcow hd2.img 3GB
And then I started QEMU again like this:
qemu -hda hd.img -hdb hd2.img -cdrom scrap1.iso -kernel-kqemu
(hd.img already had Windows installed on it, so I left it there.)
But I went to control panel > administrative tools > disk management and
right-clicked the empty hard drive to make a new partition, I got this:
EAX=bf3a77dc EBX=bf3a7ac0 ECX=bf3a7588 EDX=00000000
ESI=00000000 EDI=00000100 EBP=bf3a77c4 ESP=bf3a7514
EIP=a0086b2b EFL=00010246 [---Z-P-] CPL=3 II=0 A20=1 SMM=0 HLT=0
ES =0023 00000000 ffffffff 00cff300
CS =0008 00000000 ffffffff 00cffb00
SS =0010 00000000 ffffffff 00cff300
DS =0023 00000000 ffffffff 00cff300
FS =003b 7ffde000 00000fff 7f40f3fd
GS =0000 00000000 00000000 00000000
LDT=0000 00000000 00000000 00008000
TR =0028 8066b000 000020ab 80008966
GDT= 80036000 000003ff
IDT= 80036400 000007ff
CR0=e001003b CR2=000b9005 CR3=060e1000 CR4=00000690
Unsupported return value: 0xffffffff
And QEMU just closed. I'm not sure if this is a QEMU bug, a FreeBSD bug, or
a Windows bug, but I guess it's worth reporting here anyway.
P.S. I just tried it with -no-kqemu and it worked fine. So I think it's a
kqemu bug. I can't find a kqemu bug reporting place, so I guess this is the
next best place to report it.
[-- Attachment #2: Type: text/html, Size: 1547 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Qemu-devel] Bug report
@ 2005-11-01 23:48 Julien Lancien
2005-11-01 23:57 ` Mike Kronenberg
2005-11-02 0:00 ` Karl Magdsick
0 siblings, 2 replies; 14+ messages in thread
From: Julien Lancien @ 2005-11-01 23:48 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 316 bytes --]
Hi,
I am unable to compile qemu on my machine :p. I've attached the result
of the configure and make.
My gcc version is: 4.0.3 20051006 and kernel 2.6.13 vanilla.
I used the CVS snapshot, but I got mostly the same problem with the
0.7.2 version.
Tell me if you want more infos, and thanks for any help.
[-- Attachment #2: log-configure --]
[-- Type: application/octet-stream, Size: 817 bytes --]
Install prefix /usr/local
BIOS directory /usr/local/share/qemu
binary directory /usr/local/bin
Manual directory /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path /tmp/qemu-snapshot-2005-11-01_23
C compiler gcc
Host C compiler gcc
make make
host CPU i386
host big endian no
target list i386-user arm-user armeb-user sparc-user ppc-user i386-softmmu ppc-softmmu sparc-softmmu x86_64-softmmu mips-softmmu
gprof enabled no
static build no
SDL support yes
SDL static link yes
mingw32 support no
Adlib support no
CoreAudio support no
ALSA support no
DSound support no
FMOD support no
kqemu support yes
KQEMU Linux module configuration:
kernel sources /lib/modules/2.6.13-ARCH/build
kbuild type 2.6
[-- Attachment #3: log-make --]
[-- Type: application/octet-stream, Size: 15914 bytes --]
gcc -Wall -O2 -g -fno-strict-aliasing -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o dyngen dyngen.c
dyngen.c: In function 'load_object':
dyngen.c:508: warning: pointer targets in assignment differ in signedness
dyngen.c:544: warning: pointer targets in assignment differ in signedness
gcc -DQEMU_TOOL -Wall -O2 -g -fno-strict-aliasing -g -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o qemu-img qemu-img.c block.c block-cow.c block-qcow.c aes.c block-vmdk.c block-cloop.c block-dmg.c block-bochs.c block-vpc.c block-vvfat.c -lz
block-cloop.c: In function 'cloop_read_block':
block-cloop.c:116: warning: pointer targets in assignment differ in signedness
block-cloop.c:118: warning: pointer targets in assignment differ in signedness
block-dmg.c: In function 'dmg_read_chunk':
block-dmg.c:231: warning: pointer targets in assignment differ in signedness
block-dmg.c:233: warning: pointer targets in assignment differ in signedness
block-vpc.c: In function 'vpc_probe':
block-vpc.c:84: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness
block-vpc.c:84: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness
block-vpc.c:84: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness
block-vpc.c:84: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness
block-vpc.c:84: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness
block-vpc.c:84: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness
block-vpc.c:84: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness
block-vpc.c:84: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness
block-vvfat.c: In function 'create_long_filename':
block-vvfat.c:325: warning: pointer targets in passing argument 1 of 'short2long_name' differ in signedness
block-vvfat.c: In function 'fat_get':
block-vvfat.c:393: warning: pointer targets in initialization differ in signedness
block-vvfat.c: In function 'long2unix_name':
block-vvfat.c:446: warning: pointer targets in passing argument 1 of '__builtin_strncpy' differ in signedness
block-vvfat.c:446: warning: pointer targets in passing argument 2 of '__builtin_strncpy' differ in signedness
block-vvfat.c:453: warning: pointer targets in passing argument 1 of '__builtin_strncpy' differ in signedness
block-vvfat.c:453: warning: pointer targets in passing argument 2 of '__builtin_strncpy' differ in signedness
block-vvfat.c: In function 'create_short_filename':
block-vvfat.c:492: warning: pointer targets in passing argument 1 of '__builtin_strncpy' differ in signedness
block-vvfat.c: In function 'init_directory':
block-vvfat.c:719: warning: pointer targets in passing argument 1 of 'snprintf' differ in signedness
block-vvfat.c: In function 'vvfat_write':
block-vvfat.c:1620: warning: pointer targets in passing argument 1 of 'long2unix_name' differ in signedness
for d in i386-user arm-user armeb-user sparc-user ppc-user i386-softmmu ppc-softmmu sparc-softmmu x86_64-softmmu mips-softmmu; do \
make -C $d all || exit 1 ; \
done
make[1]: Entering directory `/tmp/qemu-snapshot-2005-11-01_23/i386-user'
gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. -I/tmp/qemu-snapshot-2005-11-01_23/target-i386 -I/tmp/qemu-snapshot-2005-11-01_23 -I/tmp/qemu-snapshot-2005-11-01_23/linux-user -I/tmp/qemu-snapshot-2005-11-01_23/linux-user/i386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/tmp/qemu-snapshot-2005-11-01_23/fpu -DHAS_AUDIO -I/tmp/qemu-snapshot-2005-11-01_23/slirp -c -o elfload.o /tmp/qemu-snapshot-2005-11-01_23/linux-user/elfload.c
/tmp/qemu-snapshot-2005-11-01_23/linux-user/elfload.c: In function 'load_elf_binary':
/tmp/qemu-snapshot-2005-11-01_23/linux-user/elfload.c:970: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/elfload.c:970: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/elfload.c:970: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/elfload.c:970: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/elfload.c:970: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/elfload.c:970: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/elfload.c:970: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/elfload.c:970: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/elfload.c:1108: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/elfload.c:1108: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/elfload.c:1108: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/elfload.c:1108: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/elfload.c:1108: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/elfload.c:1108: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/elfload.c:1108: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/elfload.c:1108: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness
gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. -I/tmp/qemu-snapshot-2005-11-01_23/target-i386 -I/tmp/qemu-snapshot-2005-11-01_23 -I/tmp/qemu-snapshot-2005-11-01_23/linux-user -I/tmp/qemu-snapshot-2005-11-01_23/linux-user/i386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/tmp/qemu-snapshot-2005-11-01_23/fpu -DHAS_AUDIO -I/tmp/qemu-snapshot-2005-11-01_23/slirp -c -o main.o /tmp/qemu-snapshot-2005-11-01_23/linux-user/main.c
gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. -I/tmp/qemu-snapshot-2005-11-01_23/target-i386 -I/tmp/qemu-snapshot-2005-11-01_23 -I/tmp/qemu-snapshot-2005-11-01_23/linux-user -I/tmp/qemu-snapshot-2005-11-01_23/linux-user/i386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/tmp/qemu-snapshot-2005-11-01_23/fpu -DHAS_AUDIO -I/tmp/qemu-snapshot-2005-11-01_23/slirp -c -o syscall.o /tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c: In function 'do_getsockopt':
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:647: warning: pointer targets in passing argument 5 of 'getsockopt' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:680: warning: pointer targets in passing argument 5 of 'getsockopt' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c: In function 'do_syscall':
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:1750: warning: pointer targets in passing argument 1 of 'tswap32s' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:1784: warning: pointer targets in passing argument 1 of 'tswap32s' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:1870: warning: pointer targets in passing argument 1 of 'tswap32s' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:1871: warning: pointer targets in passing argument 1 of 'tswap32s' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:2301: warning: pointer targets in passing argument 1 of 'tswap32s' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:2302: warning: pointer targets in passing argument 1 of 'tswap32s' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:2303: warning: pointer targets in passing argument 1 of 'tswap32s' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:2304: warning: pointer targets in passing argument 1 of 'tswap32s' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:2305: warning: pointer targets in passing argument 1 of 'tswap32s' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:2306: warning: pointer targets in passing argument 1 of 'tswap32s' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:2307: warning: pointer targets in passing argument 1 of 'tswap32s' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:2308: warning: pointer targets in passing argument 1 of 'tswap32s' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:2309: warning: pointer targets in passing argument 1 of 'tswap32s' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:2310: warning: pointer targets in passing argument 1 of 'tswap32s' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:2630: warning: pointer targets in passing argument 1 of 'tswap64s' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:2934: warning: pointer targets in passing argument 1 of 'getresuid' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:2934: warning: pointer targets in passing argument 2 of 'getresuid' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:2934: warning: pointer targets in passing argument 3 of 'getresuid' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:2954: warning: pointer targets in passing argument 1 of 'getresgid' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:2954: warning: pointer targets in passing argument 2 of 'getresgid' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:2954: warning: pointer targets in passing argument 3 of 'getresgid' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:3061: warning: pointer targets in passing argument 1 of 'getresuid' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:3061: warning: pointer targets in passing argument 2 of 'getresuid' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:3061: warning: pointer targets in passing argument 3 of 'getresuid' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:3079: warning: pointer targets in passing argument 1 of 'getresgid' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:3079: warning: pointer targets in passing argument 2 of 'getresgid' differ in signedness
/tmp/qemu-snapshot-2005-11-01_23/linux-user/syscall.c:3079: warning: pointer targets in passing argument 3 of 'getresgid' differ in signedness
gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. -I/tmp/qemu-snapshot-2005-11-01_23/target-i386 -I/tmp/qemu-snapshot-2005-11-01_23 -I/tmp/qemu-snapshot-2005-11-01_23/linux-user -I/tmp/qemu-snapshot-2005-11-01_23/linux-user/i386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/tmp/qemu-snapshot-2005-11-01_23/fpu -DHAS_AUDIO -I/tmp/qemu-snapshot-2005-11-01_23/slirp -c -o mmap.o /tmp/qemu-snapshot-2005-11-01_23/linux-user/mmap.c
gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. -I/tmp/qemu-snapshot-2005-11-01_23/target-i386 -I/tmp/qemu-snapshot-2005-11-01_23 -I/tmp/qemu-snapshot-2005-11-01_23/linux-user -I/tmp/qemu-snapshot-2005-11-01_23/linux-user/i386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/tmp/qemu-snapshot-2005-11-01_23/fpu -DHAS_AUDIO -I/tmp/qemu-snapshot-2005-11-01_23/slirp -c -o signal.o /tmp/qemu-snapshot-2005-11-01_23/linux-user/signal.c
gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. -I/tmp/qemu-snapshot-2005-11-01_23/target-i386 -I/tmp/qemu-snapshot-2005-11-01_23 -I/tmp/qemu-snapshot-2005-11-01_23/linux-user -I/tmp/qemu-snapshot-2005-11-01_23/linux-user/i386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/tmp/qemu-snapshot-2005-11-01_23/fpu -DHAS_AUDIO -I/tmp/qemu-snapshot-2005-11-01_23/slirp -c -o path.o /tmp/qemu-snapshot-2005-11-01_23/linux-user/path.c
gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. -I/tmp/qemu-snapshot-2005-11-01_23/target-i386 -I/tmp/qemu-snapshot-2005-11-01_23 -I/tmp/qemu-snapshot-2005-11-01_23/linux-user -I/tmp/qemu-snapshot-2005-11-01_23/linux-user/i386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/tmp/qemu-snapshot-2005-11-01_23/fpu -DHAS_AUDIO -I/tmp/qemu-snapshot-2005-11-01_23/slirp -c -o osdep.o /tmp/qemu-snapshot-2005-11-01_23/osdep.c
gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. -I/tmp/qemu-snapshot-2005-11-01_23/target-i386 -I/tmp/qemu-snapshot-2005-11-01_23 -I/tmp/qemu-snapshot-2005-11-01_23/linux-user -I/tmp/qemu-snapshot-2005-11-01_23/linux-user/i386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/tmp/qemu-snapshot-2005-11-01_23/fpu -DHAS_AUDIO -I/tmp/qemu-snapshot-2005-11-01_23/slirp -c -o thunk.o /tmp/qemu-snapshot-2005-11-01_23/thunk.c
gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. -I/tmp/qemu-snapshot-2005-11-01_23/target-i386 -I/tmp/qemu-snapshot-2005-11-01_23 -I/tmp/qemu-snapshot-2005-11-01_23/linux-user -I/tmp/qemu-snapshot-2005-11-01_23/linux-user/i386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/tmp/qemu-snapshot-2005-11-01_23/fpu -DHAS_AUDIO -I/tmp/qemu-snapshot-2005-11-01_23/slirp -c -o vm86.o /tmp/qemu-snapshot-2005-11-01_23/linux-user/vm86.c
gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. -I/tmp/qemu-snapshot-2005-11-01_23/target-i386 -I/tmp/qemu-snapshot-2005-11-01_23 -I/tmp/qemu-snapshot-2005-11-01_23/linux-user -I/tmp/qemu-snapshot-2005-11-01_23/linux-user/i386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/tmp/qemu-snapshot-2005-11-01_23/fpu -DHAS_AUDIO -I/tmp/qemu-snapshot-2005-11-01_23/slirp -c -o exec.o /tmp/qemu-snapshot-2005-11-01_23/exec.c
/tmp/qemu-snapshot-2005-11-01_23/exec.c: In function 'cpu_set_log':
/tmp/qemu-snapshot-2005-11-01_23/exec.c:1257: warning: pointer targets in passing argument 2 of 'setvbuf' differ in signedness
gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. -I/tmp/qemu-snapshot-2005-11-01_23/target-i386 -I/tmp/qemu-snapshot-2005-11-01_23 -I/tmp/qemu-snapshot-2005-11-01_23/linux-user -I/tmp/qemu-snapshot-2005-11-01_23/linux-user/i386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/tmp/qemu-snapshot-2005-11-01_23/fpu -DHAS_AUDIO -I/tmp/qemu-snapshot-2005-11-01_23/slirp -c -o kqemu.o /tmp/qemu-snapshot-2005-11-01_23/kqemu.c
gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -mpreferred-stack-boundary=2 -falign-functions=0 -fno-gcse -fno-reorder-blocks -fno-optimize-sibling-calls -I. -I/tmp/qemu-snapshot-2005-11-01_23/target-i386 -I/tmp/qemu-snapshot-2005-11-01_23 -I/tmp/qemu-snapshot-2005-11-01_23/linux-user -I/tmp/qemu-snapshot-2005-11-01_23/linux-user/i386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/tmp/qemu-snapshot-2005-11-01_23/fpu -DHAS_AUDIO -I/tmp/qemu-snapshot-2005-11-01_23/slirp -c -o op.o /tmp/qemu-snapshot-2005-11-01_23/target-i386/op.c
../dyngen -o op.h op.o
dyngen: ret or jmp expected at the end of op_bsfw_T0_cc
make[1]: *** [op.h] Error 1
make[1]: Leaving directory `/tmp/qemu-snapshot-2005-11-01_23/i386-user'
make: *** [all] Error 1
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [Qemu-devel] Bug report
2005-11-01 23:48 Julien Lancien
@ 2005-11-01 23:57 ` Mike Kronenberg
2005-11-02 0:00 ` Karl Magdsick
1 sibling, 0 replies; 14+ messages in thread
From: Mike Kronenberg @ 2005-11-01 23:57 UTC (permalink / raw)
To: qemu-devel
Julien Lancien wrote:
>Hi,
>
>I am unable to compile qemu on my machine :p. I've attached the result
>of the configure and make.
>
>My gcc version is: 4.0.3 20051006 and kernel 2.6.13 vanilla.
>
>I used the CVS snapshot, but I got mostly the same problem with the
>0.7.2 version.
>Tell me if you want more infos, and thanks for any help.
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Qemu-devel mailing list
>Qemu-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
about compiling QEMU with gcc 4.x.x
http://lists.gnu.org/archive/html/qemu-devel/2005-10/msg00312.html
Greetings
Mike
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] Bug report
2005-11-01 23:48 Julien Lancien
2005-11-01 23:57 ` Mike Kronenberg
@ 2005-11-02 0:00 ` Karl Magdsick
[not found] ` <e1843770511011607m1cda6256o37102cf17cc75fea@mail.gmail.com>
` (2 more replies)
1 sibling, 3 replies; 14+ messages in thread
From: Karl Magdsick @ 2005-11-02 0:00 UTC (permalink / raw)
To: qemu-devel, calexicoz
gcc 4.x is known not to compile qemu, due to a register allocation bug in gcc.
Also, the current qemu code generator is an ugly hack that relies on some
specifics of gcc 3.x function implementation. There is work being done
on a _real_ code generator for qemu.
-Karl
On 11/1/05, Julien Lancien <calexicoz@gmail.com> wrote:
> Hi,
>
> I am unable to compile qemu on my machine :p. I've attached the result
> of the configure and make.
>
> My gcc version is: 4.0.3 20051006 and kernel 2.6.13 vanilla.
>
> I used the CVS snapshot, but I got mostly the same problem with the
> 0.7.2 version.
> Tell me if you want more infos, and thanks for any help.
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread[parent not found: <e1843770511011607m1cda6256o37102cf17cc75fea@mail.gmail.com>]
* Re: [Qemu-devel] Bug report
[not found] ` <e1843770511011607m1cda6256o37102cf17cc75fea@mail.gmail.com>
@ 2005-11-02 0:08 ` Julien Lancien
2005-11-02 0:42 ` Jim C. Brown
0 siblings, 1 reply; 14+ messages in thread
From: Julien Lancien @ 2005-11-02 0:08 UTC (permalink / raw)
To: qemu-devel
On 11/1/05, Karl Magdsick <kmagnum@gmail.com> wrote:
> gcc 4.x is known not to compile qemu, due to a register allocation bug in gcc.
>
> Also, the current qemu code generator is an ugly hack that relies on some
> specifics of gcc 3.x function implementation. There is work being done
> on a _real_ code generator for qemu.
I saw that there is a binary distribution for linux-i386, however,
I'ld like to also get kqemu. Is there a way to do that without getting
gcc 3 ?
Thanks.
Ps: this is a forward, I forgot to copy the ml.
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [Qemu-devel] Bug report
2005-11-02 0:08 ` Julien Lancien
@ 2005-11-02 0:42 ` Jim C. Brown
0 siblings, 0 replies; 14+ messages in thread
From: Jim C. Brown @ 2005-11-02 0:42 UTC (permalink / raw)
To: Julien Lancien; +Cc: qemu-devel
On Tue, Nov 01, 2005 at 07:08:19PM -0500, Julien Lancien wrote:
> I saw that there is a binary distribution for linux-i386, however,
> I'ld like to also get kqemu. Is there a way to do that without getting
> gcc 3 ?
>
> Thanks.
>
kqemu is immune to the gcc 3 problem that qemu has. You can use gcc 3 qemu
with gcc 4 kqemu and gcc 4 kernel, no problems there.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] Bug report
2005-11-02 0:00 ` Karl Magdsick
[not found] ` <e1843770511011607m1cda6256o37102cf17cc75fea@mail.gmail.com>
@ 2005-11-02 0:20 ` Philip Machanick
2005-11-02 7:03 ` Gwenole Beauchesne
2 siblings, 0 replies; 14+ messages in thread
From: Philip Machanick @ 2005-11-02 0:20 UTC (permalink / raw)
To: qemu-devel
Find out how to run gcc 3.x if you have it installed, e.g., on mine
(Mac OS X), gcc-3.3 does it, then:
./configure --cc=gcc-3.3
This seems to be enough (HOST_CC left as gcc doesn't break anything
but it may be safer to set that too as 3.x).
On 02/11/2005, at 10:00 AM, Karl Magdsick wrote:
> gcc 4.x is known not to compile qemu, due to a register allocation
> bug in gcc.
>
> Also, the current qemu code generator is an ugly hack that relies
> on some
> specifics of gcc 3.x function implementation. There is work being
> done
> on a _real_ code generator for qemu.
>
>
> -Karl
>
> On 11/1/05, Julien Lancien <calexicoz@gmail.com> wrote:
>> Hi,
>>
>> I am unable to compile qemu on my machine :p. I've attached the
>> result
>> of the configure and make.
>>
>> My gcc version is: 4.0.3 20051006 and kernel 2.6.13 vanilla.
>>
>> I used the CVS snapshot, but I got mostly the same problem with the
>> 0.7.2 version.
>> Tell me if you want more infos, and thanks for any help.
>>
>>
>> _______________________________________________
>> Qemu-devel mailing list
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>
>>
>>
>>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
Philip Machanick School of ITEE, University of
Queensland
Brisbane, Qld 4072, Australia http://www.itee.uq.edu.au/
~philip/
phone +61(7) 3365 2766 fax +61(7) 3365 4999
mailto:philip@itee.uq.edu.au
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [Qemu-devel] Bug report
2005-11-02 0:00 ` Karl Magdsick
[not found] ` <e1843770511011607m1cda6256o37102cf17cc75fea@mail.gmail.com>
2005-11-02 0:20 ` Philip Machanick
@ 2005-11-02 7:03 ` Gwenole Beauchesne
2 siblings, 0 replies; 14+ messages in thread
From: Gwenole Beauchesne @ 2005-11-02 7:03 UTC (permalink / raw)
To: qemu-devel; +Cc: calexicoz
Le mercredi, 2 nov 2005, à 01:00 Europe/Paris, Karl Magdsick a écrit :
> gcc 4.x is known not to compile qemu, due to a register allocation bug
> in gcc.
It can be fixed at QEMU's level with additional patches than posted
here and actually I have it working for x86 system emulation.
Unfortunately, it crashes for x86_64 system emulation. I have yet to
review the generated ops for 64-bit targets but this won't happen
immediately, probably in two weeks...
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Qemu-devel] Bug report
@ 2004-04-11 15:04 J. Mayer
0 siblings, 0 replies; 14+ messages in thread
From: J. Mayer @ 2004-04-11 15:04 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 480 bytes --]
I just had a SIGSEGV, running qemu under gdb on my PC. Here's the case:
we enter tb_link_phys with phys_pc == 0
Then, we crash in tb_alloc_page because the PageDesc returned by
page_find is NULL.
So, dereferencing this pointer, we get a segfault:
p = page_find(page_addr >> TARGET_PAGE_BITS);
tb->page_next[n] = p->first_tb;
^^^^^^
You'll find useful informations in gdb output, attached.
--
J. Mayer <l_indien@magic.fr>
Never organized
[-- Attachment #2: Qemu segfault gdb output --]
[-- Type: text/plain, Size: 3316 bytes --]
(qemu)
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 27064)]
tb_link_phys (tb=0x83ff094, phys_pc=0, phys_page2=4294967295)
at /home/jocelyn/devel/ppc_emul/qemu-newCVS/qemu/exec.c:694
694 tb->page_next[n] = p->first_tb;
(gdb) bt
#0 tb_link_phys (tb=0x83ff094, phys_pc=0, phys_page2=4294967295)
at /home/jocelyn/devel/ppc_emul/qemu-newCVS/qemu/exec.c:694
#1 0x0806a38c in cpu_ppc_exec (env1=0x8f007c0)
at /home/jocelyn/devel/ppc_emul/qemu-newCVS/qemu/cpu-exec.c:346
#2 0x0804b839 in main_loop ()
at /home/jocelyn/devel/ppc_emul/qemu-newCVS/qemu/vl.c:1528
#3 0x0804c453 in main (argc=134526736, argv=0xbffff124)
at /home/jocelyn/devel/ppc_emul/qemu-newCVS/qemu/vl.c:2170
(gdb) p tb
= (TranslationBlock *) 0x83ff094
(gdb) p/x *tb
= {pc = 0x7ffff660, cs_base = 0x0, flags = 0x0, size = 0x4, cflags = 0x0,
tc_ptr = 0x8de24c0, hash_next = 0x0, phys_hash_next = 0x83919d8,
page_next = {0x0, 0x0}, page_addr = {0x37962000, 0x0}, tb_next_offset = {
0xffff, 0xffff}, tb_jmp_offset = {0x0, 0x0, 0xffff, 0xffff}, jmp_next = {
0x0, 0x0}, jmp_first = 0x0}
(gdb) p/x l1_map[0]
= 0x8f18b10
(gdb) p/x *l1_map[0]
= {phys_offset = 0x0, first_tb = 0x83ff050, code_write_count = 0x0,
code_bitmap = 0x0}
(gdb) info registers
eax 0x0 0
ecx 0x83919d8 137959896
edx 0x37962 227682
ebx 0x0 0
esp 0xbfffdc50 0xbfffdc50
ebp 0x8f007c0 0x8f007c0
esi 0x83ff094 138408084
edi 0xffffffff -1
eip 0x8060886 0x8060886
eflags 0x10246 66118
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x7 7
(gdb) disas
Dump of assembler code for function tb_link_phys:
0x08060830 <tb_link_phys+0>: push %ebp
0x08060831 <tb_link_phys+1>: push %edi
0x08060832 <tb_link_phys+2>: push %esi
0x08060833 <tb_link_phys+3>: push %ebx
0x08060834 <tb_link_phys+4>: sub bashxc,%esp
0x08060837 <tb_link_phys+7>: xor %ebx,%ebx
0x08060839 <tb_link_phys+9>: mov 0x24(%esp,1),%eax
0x0806083d <tb_link_phys+13>: mov 0x20(%esp,1),%esi
0x08060841 <tb_link_phys+17>: mov 0x28(%esp,1),%edi
0x08060845 <tb_link_phys+21>: mov %eax,%edx
0x08060847 <tb_link_phys+23>: and bashx7fff,%edx
0x0806084d <tb_link_phys+29>: and bashxfffff000,%eax
0x08060852 <tb_link_phys+34>: mov %eax,0x24(%esi)
0x08060855 <tb_link_phys+37>: shl bashx2,%edx
0x08060858 <tb_link_phys+40>: mov 0x8278780(%edx),%ecx
0x0806085e <tb_link_phys+46>: mov %ecx,0x18(%esi)
0x08060861 <tb_link_phys+49>: mov %esi,0x8278780(%edx)
0x08060867 <tb_link_phys+55>: mov %eax,%edx
0x08060869 <tb_link_phys+57>: shr bashx16,%eax
0x0806086c <tb_link_phys+60>: mov 0x80a55a0(,%eax,4),%eax
0x08060873 <tb_link_phys+67>: shr bashxc,%edx
0x08060876 <tb_link_phys+70>: test %eax,%eax
0x08060878 <tb_link_phys+72>: je 0x8060886 <tb_link_phys+86>
0x0806087a <tb_link_phys+74>: and bashx3ff,%edx
0x08060880 <tb_link_phys+80>: shl bashx4,%edx
0x08060883 <tb_link_phys+83>: lea (%edx,%eax,1),%ebx
0x08060886 <tb_link_phys+86>: mov 0x4(%ebx),%edx
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-10-06 16:56 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-11 12:07 [Qemu-devel] bug report Artem Kozarezov
-- strict thread matches above, loose matches on Subject: below --
2013-10-06 16:55 Peter Cheung
2007-12-17 13:48 [Qemu-devel] Bug report Bas Wijnen
2007-12-18 16:52 ` Paul Brook
2007-12-19 1:11 ` Bas Wijnen
2006-12-03 16:40 Mike Smith
2005-11-01 23:48 Julien Lancien
2005-11-01 23:57 ` Mike Kronenberg
2005-11-02 0:00 ` Karl Magdsick
[not found] ` <e1843770511011607m1cda6256o37102cf17cc75fea@mail.gmail.com>
2005-11-02 0:08 ` Julien Lancien
2005-11-02 0:42 ` Jim C. Brown
2005-11-02 0:20 ` Philip Machanick
2005-11-02 7:03 ` Gwenole Beauchesne
2004-04-11 15:04 J. Mayer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).