diff options
Diffstat (limited to 'results/classifier/zero-shot/118/assembly')
| -rw-r--r-- | results/classifier/zero-shot/118/assembly/1649 | 77 | ||||
| -rw-r--r-- | results/classifier/zero-shot/118/assembly/1806114 | 140 | ||||
| -rw-r--r-- | results/classifier/zero-shot/118/assembly/1809144 | 101 | ||||
| -rw-r--r-- | results/classifier/zero-shot/118/assembly/1862167 | 79 | ||||
| -rw-r--r-- | results/classifier/zero-shot/118/assembly/2463 | 69 |
5 files changed, 466 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/118/assembly/1649 b/results/classifier/zero-shot/118/assembly/1649 new file mode 100644 index 000000000..6925a7513 --- /dev/null +++ b/results/classifier/zero-shot/118/assembly/1649 @@ -0,0 +1,77 @@ +assembly: 0.984 +graphic: 0.900 +register: 0.898 +performance: 0.866 +files: 0.863 +device: 0.747 +ppc: 0.734 +architecture: 0.650 +semantic: 0.642 +peripherals: 0.624 +kernel: 0.615 +vnc: 0.610 +network: 0.592 +socket: 0.542 +hypervisor: 0.516 +mistranslation: 0.500 +debug: 0.494 +risc-v: 0.474 +i386: 0.452 +TCG: 0.444 +PID: 0.443 +x86: 0.440 +VMM: 0.433 +arm: 0.411 +permissions: 0.398 +boot: 0.379 +user-level: 0.365 +KVM: 0.352 +virtual: 0.169 +-------------------- +assembly: 0.998 +debug: 0.701 +user-level: 0.563 +register: 0.136 +TCG: 0.096 +kernel: 0.053 +files: 0.048 +PID: 0.026 +virtual: 0.025 +semantic: 0.025 +x86: 0.018 +arm: 0.014 +device: 0.014 +network: 0.013 +hypervisor: 0.010 +ppc: 0.010 +risc-v: 0.009 +architecture: 0.008 +VMM: 0.007 +peripherals: 0.007 +socket: 0.007 +performance: 0.005 +boot: 0.004 +graphic: 0.003 +vnc: 0.002 +permissions: 0.002 +i386: 0.001 +KVM: 0.001 +mistranslation: 0.001 + +"slli" instruction before "la" and "csrw" sequence leads to failure in setting the cs register +Description of problem: +slli a0, a0, 8 (1) + la a0, mtimvec (2) + csrw mtvec, a0 (3) + mtimvec: (4) + +For the above assembly snippet, the mtvec could be successfully set to the value of a0 +without the presence of the line (1) or with the shift amount being zero. However, +the mtvec can never be set successfully with the presence of line (1). +Steps to reproduce: +1. Create a test.s file and put these 4 lines of assembly into the file +2. In terminal, run: "riscv64-unknown-elf-gcc -Ttext 0x80000000 -c test.s -o test", "riscv64-unknown-elf-objcopy test -S -O binary test", and "qemu-system-riscv64 test -s -S" +3. In another terminal window, run [riscv64-unknown-elf-gdb -ex "target remote localhost:1234" -ex "layout asm"]. Keep running si command in gdb until you are at 0x80000000 where you shall see the first instruction as shown in line (1). Then keep going till you have stepped over the instruction shown in line (3). Now, run "p $mtvec" in gdb, you shall see its value being 0. +4. Redo the above steps without line (1), you shall see mtvec loaded successfully with the correct value. +Additional information: + diff --git a/results/classifier/zero-shot/118/assembly/1806114 b/results/classifier/zero-shot/118/assembly/1806114 new file mode 100644 index 000000000..b586171b8 --- /dev/null +++ b/results/classifier/zero-shot/118/assembly/1806114 @@ -0,0 +1,140 @@ +assembly: 0.860 +virtual: 0.850 +graphic: 0.823 +peripherals: 0.820 +architecture: 0.817 +performance: 0.807 +device: 0.798 +permissions: 0.782 +i386: 0.760 +register: 0.759 +PID: 0.759 +ppc: 0.754 +user-level: 0.753 +debug: 0.750 +network: 0.746 +x86: 0.742 +risc-v: 0.740 +VMM: 0.735 +socket: 0.724 +files: 0.722 +TCG: 0.721 +hypervisor: 0.706 +KVM: 0.703 +boot: 0.697 +kernel: 0.693 +arm: 0.678 +semantic: 0.675 +mistranslation: 0.659 +vnc: 0.631 +-------------------- +i386: 1.000 +assembly: 0.995 +x86: 0.980 +debug: 0.381 +virtual: 0.317 +TCG: 0.069 +boot: 0.032 +PID: 0.022 +files: 0.020 +user-level: 0.019 +hypervisor: 0.017 +network: 0.016 +ppc: 0.014 +kernel: 0.013 +VMM: 0.012 +register: 0.008 +device: 0.007 +socket: 0.005 +risc-v: 0.005 +performance: 0.005 +peripherals: 0.004 +semantic: 0.003 +graphic: 0.003 +vnc: 0.003 +architecture: 0.002 +permissions: 0.001 +mistranslation: 0.000 +arm: 0.000 +KVM: 0.000 + +Reading sectors from floppy with BIOS INT 13h is broken + +I'm developing a game bootable from a floppy disk, written in i386 assembly. I found out it doesn't work on newer QEMU versions. I managed to isolate the issue and it seems that there's a problem with handling of BIOS interrupt 13h when it comes to reading disk sectors (AH=02). + +I've written a simple test in assembly. It simply accesses four different floppy disk sectors and prints out the strings they contain. The problem is, the two latter strings don't show up at all nor the BIOS interrupt returns an error (CF set). I've attached the code to this bug report. I use following commands to compile it and run: + +$ nasm disk-test.asm -o disk-test.bin +$ qemu-system-i386 -boot a -fda disk-test.bin + +After running, the expected output is: + + I am a test string from boot sector + C:H:S 0:0:2 - Hello + C:H:S 0:0:3 - there! + C:H:S 0:1:4 - In QEMU you can't + C:H:S 1:0:5 - see these two lines! :( + +while the actual output is: + + I am a test string from boot sector + C:H:S 0:0:2 - Hello + C:H:S 0:0:3 - there! + + +So far, I found this problem in the current QEMU version for Ubuntu 18.04 (Debian 1:2.11+dfsg-1ubuntu7.8), as well as in the 3.1.0-rc3 and 2.12.1 versions, available on the www.qemu.org website. Thus, the issue doesn't seem to be very recent. + +To be sure, I ran the program on my other machine with older QEMU version (Debian 2.0.0+dfsg-2ubuntu1.43) and on my RaspberryPi 2 (Debian 1.1.2+dfsg-6+deb7u25) and everything works as expected there. It also works well in VirtualBox. + +I hope these information are useful to you, however, I feel like this bug may be more related to Seabios. If so, please let me know and I will report it somewhere else. + + + +Hello! Thank you for your kindly and detailed report. + +Since this is via the INT 13h mechanism, the problem is likely in SeaBIOS. + +If I'm reading the version strings right, it looks like QEMU 2.0.0 QEMU 1.1.2 appear to be working correctly for you, but do you know what versions of the SeaBIOS firmware they're running with? + +It might be interesting to see if, on QEMU 2.0.0 but a modern version of SeaBIOS, that it still breaks the same way -- that way we can tell for sure if it's a QEMU regression or a SeaBIOS one. + +Thank you, +--js + +I ran plenty of QEMU/SeaBIOS configurations and these are the results: + +Ubuntu 18.04: + OK --> QEMU qemu-2.0.0 + SEABIOS rel-1.7.4-0-g96917a8 + OK --> QEMU qemu-2.0.0 + SEABIOS 1.10.2-1ubuntu1 (default) + BAD --> QEMU Debian 1:2.11+dfsg-1ubuntu7.8 (default) + SEABIOS 1.10.2-1ubuntu1 (default) + BAD --> QEMU Debian 1:2.11+dfsg-1ubuntu7.8 (default) + SEABIOS 1.7.4-4ubuntu1 + BAD --> QEMU qemu-3.1.0-rc3 + SEABIOS rel-1.12.0-0-ga698c89 + +Ubuntu 14.04: + OK --> QEMU Debian 2.0.0+dfsg-2ubuntu1.44 (default) + SEABIOS 1.7.4-4ubuntu1 (default) + OK --> QEMU Debian 2.0.0+dfsg-2ubuntu1.44 (default) + SEABIOS rel-1.12.0-0-ga698c89 + BAD --> QEMU qemu-3.1.0-rc3 + SEABIOS 1.7.4-4ubuntu1 (default) + BAD --> QEMU qemu-3.1.0-rc3 + SEABIOS rel-1.12.0-0-ga698c89 + +Kali Linux (Debian 4.17.8-1kali1): + OK --> QEMU qemu-2.0.0 + SEABIOS rel-1.7.4-0-g96917a8 + OK --> QEMU qemu-2.0.0 + SEABIOS 1.11.1-1 (default) + BAD --> QEMU Debian 1:2.12+dfsg-3+b1 (default) + SEABIOS 1.11.1-1 (default) + BAD --> QEMU Debian 1:2.12+dfsg-3+b1 (default) + SEABIOS rel-1.7.4-0-g96917a8 + BAD --> QEMU qemu-3.1.0-rc3 + SEABIOS rel-1.12.0-0-ga698c89 + +Surprisingly, it seems that the problem is in QEMU. I didn't test versions between 2.0 and 2.12, because I had some issues with building (util/memfd.c:43:12: error: static declaration of ‘memfd_create’ follows non-static declaration). I'll try to fix it by hand and will let you know if I manage to determine what's the first version to cause problems. + +Alright, I managed to compile 2.5.0, 2.5.1 and 2.6.0 by simply making memfd_create() non-static. + +It turns out that 2.6.0 is the first version causing problems. I tested each of these with the provided SeaBIOS version and with SeaBIOS rel-1.7.4-0-g96917a8. + +The memfd_create() compilation failure is a bug in older QEMU versions that was only revealed by a newer glibc version (ie old QEMU built OK with older glibc but fails with newer glibc). It's fixed in git in commit 75e5b70e6b5dcc4f221, so backporting that to the older versions you're trying to build is probably the correct fix there, though it sounds like you've sufficiently worked around it anyway. + +I see. That wasn't much of a problem, but thank you for the information. I'll try to keep it in mind when building QEMU in future. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/118/assembly/1809144 b/results/classifier/zero-shot/118/assembly/1809144 new file mode 100644 index 000000000..095991c70 --- /dev/null +++ b/results/classifier/zero-shot/118/assembly/1809144 @@ -0,0 +1,101 @@ +assembly: 0.884 +performance: 0.775 +ppc: 0.755 +graphic: 0.745 +architecture: 0.736 +mistranslation: 0.706 +device: 0.703 +debug: 0.685 +virtual: 0.662 +vnc: 0.649 +network: 0.644 +PID: 0.642 +hypervisor: 0.633 +kernel: 0.626 +VMM: 0.613 +files: 0.607 +register: 0.597 +user-level: 0.591 +peripherals: 0.581 +risc-v: 0.580 +x86: 0.574 +socket: 0.572 +semantic: 0.566 +permissions: 0.551 +arm: 0.538 +i386: 0.537 +TCG: 0.519 +boot: 0.424 +KVM: 0.362 +-------------------- +user-level: 0.876 +assembly: 0.846 +x86: 0.702 +kernel: 0.631 +debug: 0.083 +virtual: 0.072 +TCG: 0.035 +arm: 0.029 +i386: 0.023 +files: 0.017 +hypervisor: 0.013 +semantic: 0.011 +performance: 0.010 +architecture: 0.010 +risc-v: 0.006 +ppc: 0.005 +PID: 0.003 +network: 0.003 +peripherals: 0.003 +register: 0.003 +boot: 0.002 +device: 0.002 +vnc: 0.002 +permissions: 0.001 +graphic: 0.001 +VMM: 0.000 +socket: 0.000 +mistranslation: 0.000 +KVM: 0.000 + +SVM instructions fail with SVME bit enabled + +I was trying to use QEMU/TCG to emulate some stuff that uses SVM. +I know SVM is only partially implemented but I gave it a try anyway. + +I found that if SVM is enabled in the same basic block in which there's a call to VMSAVE/etc, +the call fails as illegal op because the flags don't get updated correctly. + +The pseudocode for the asm I'm running is: + +``` +EFER |= SVME; set the appropriate bit with wrmsr +vmsave +``` + +This is an example of the relevant translate.c code: + +``` + if (!(s->flags & HF_SVME_MASK) || !s->pe) { + goto illegal_op; + } + if (s->cpl != 0) { + gen_exception(s, EXCP0D_GPF, pc_start - s->cs_base); + break; + } +``` + +s->flags doesn't get updated after the wrmsr instruction and so QEMU raises an illegal opcode interrupt. + +A quick fix is to make the tb end after `wrmsr` instructions, but it's an hack afaik. +I'm not too comfortable with QEMU's code, so I don't know what a proper fix would be. + +Cheers, + +thebabush + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/118/assembly/1862167 b/results/classifier/zero-shot/118/assembly/1862167 new file mode 100644 index 000000000..7c6267a86 --- /dev/null +++ b/results/classifier/zero-shot/118/assembly/1862167 @@ -0,0 +1,79 @@ +assembly: 0.936 +architecture: 0.846 +graphic: 0.779 +arm: 0.771 +performance: 0.718 +device: 0.706 +register: 0.659 +semantic: 0.633 +vnc: 0.621 +ppc: 0.620 +risc-v: 0.577 +x86: 0.565 +network: 0.540 +VMM: 0.523 +kernel: 0.515 +i386: 0.503 +mistranslation: 0.456 +PID: 0.448 +permissions: 0.438 +TCG: 0.436 +hypervisor: 0.435 +socket: 0.431 +user-level: 0.406 +files: 0.399 +KVM: 0.390 +boot: 0.382 +debug: 0.339 +peripherals: 0.263 +virtual: 0.253 +-------------------- +arm: 0.996 +user-level: 0.853 +assembly: 0.493 +virtual: 0.353 +register: 0.181 +hypervisor: 0.140 +files: 0.068 +semantic: 0.034 +performance: 0.034 +architecture: 0.027 +TCG: 0.022 +debug: 0.020 +PID: 0.013 +VMM: 0.006 +kernel: 0.006 +KVM: 0.005 +network: 0.005 +device: 0.004 +socket: 0.003 +peripherals: 0.002 +risc-v: 0.002 +boot: 0.002 +permissions: 0.002 +graphic: 0.001 +vnc: 0.001 +x86: 0.001 +ppc: 0.001 +i386: 0.001 +mistranslation: 0.000 + +Variation of SVE register size (qemu-user-aarch64) + +Specification of ARMv8-A SVE extention allows various values for the size of the SVE register. On the other hand, it seems that the current qemu-aarch64 supports only the maximum length of 2048 bits as the SVE register size. I am writing an assembler program for a CPU that is compliant with ARMv8-A + SVE and has a 512-bit SVE register, but when this is run with qemu-user-aarch64, a 2048-bit load / store instruction is executed This causes a segmentation fault. Shouldn't qeum-user-aarch64 have an option to specify the SVE register size? + +This is already managed by a cpu property. + +0df9142d27d5 ("target/arm/cpu64: max cpu: Introduce sve<N> properties") + +See docs/arm-cpu-features.rst + +Try "-cpu max,sve512=on". + + + +Note also that the vector length in SVE is not fixed -- you should be writing your guest code to support arbitrary vector lengths, because otherwise it will not run on all SVE-supporting CPUs. + + +Thank you for your kind advice. I'll try it. + diff --git a/results/classifier/zero-shot/118/assembly/2463 b/results/classifier/zero-shot/118/assembly/2463 new file mode 100644 index 000000000..95864423a --- /dev/null +++ b/results/classifier/zero-shot/118/assembly/2463 @@ -0,0 +1,69 @@ +assembly: 0.829 +device: 0.760 +graphic: 0.752 +semantic: 0.578 +architecture: 0.531 +permissions: 0.519 +performance: 0.512 +socket: 0.454 +boot: 0.363 +PID: 0.362 +mistranslation: 0.360 +network: 0.338 +i386: 0.333 +risc-v: 0.330 +vnc: 0.307 +register: 0.305 +debug: 0.290 +ppc: 0.254 +VMM: 0.242 +x86: 0.242 +TCG: 0.238 +user-level: 0.235 +arm: 0.231 +files: 0.210 +peripherals: 0.167 +kernel: 0.141 +virtual: 0.101 +hypervisor: 0.097 +KVM: 0.091 +-------------------- +user-level: 0.992 +assembly: 0.934 +permissions: 0.066 +files: 0.047 +debug: 0.047 +kernel: 0.045 +TCG: 0.044 +virtual: 0.035 +register: 0.032 +performance: 0.021 +hypervisor: 0.017 +device: 0.016 +semantic: 0.013 +PID: 0.012 +VMM: 0.010 +risc-v: 0.005 +architecture: 0.004 +KVM: 0.003 +ppc: 0.003 +boot: 0.003 +graphic: 0.003 +peripherals: 0.003 +socket: 0.002 +network: 0.002 +arm: 0.002 +i386: 0.002 +vnc: 0.001 +x86: 0.001 +mistranslation: 0.000 + +allow sifive_e to use more RAM +Description of problem: +For users like me that are still learning RISC bare-metal assembly, searching online you will find many tutorials and examples using sifive_e with Qemu, so it is the easy way to get started. + +I quickly ran into crashes with my tests because I did not realize that sifive_e is limited to 16K of RAM. +I realize the 16K limit is hard coded so that it matches the real hardware, but that makes it very hard to run a variety of tests. +Additional information: +My fork of Qemu changes sifive_e to allow 256MB. +https://github.com/panjea/qemu/commit/97cb89d778ebe3407a969b8282e2e7adb4be2971 |