diff options
Diffstat (limited to 'results/classifier/zero-shot/118/semantic-arm')
| -rw-r--r-- | results/classifier/zero-shot/118/semantic-arm/124 | 61 | ||||
| -rw-r--r-- | results/classifier/zero-shot/118/semantic-arm/1704658 | 116 | ||||
| -rw-r--r-- | results/classifier/zero-shot/118/semantic-arm/1809546 | 137 | ||||
| -rw-r--r-- | results/classifier/zero-shot/118/semantic-arm/1812091 | 123 | ||||
| -rw-r--r-- | results/classifier/zero-shot/118/semantic-arm/714 | 103 |
5 files changed, 540 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/118/semantic-arm/124 b/results/classifier/zero-shot/118/semantic-arm/124 new file mode 100644 index 000000000..4095760d6 --- /dev/null +++ b/results/classifier/zero-shot/118/semantic-arm/124 @@ -0,0 +1,61 @@ +semantic: 0.952 +architecture: 0.948 +arm: 0.881 +device: 0.844 +register: 0.746 +performance: 0.726 +debug: 0.657 +network: 0.595 +graphic: 0.461 +risc-v: 0.246 +boot: 0.240 +peripherals: 0.234 +ppc: 0.186 +assembly: 0.173 +kernel: 0.173 +mistranslation: 0.172 +vnc: 0.123 +hypervisor: 0.098 +i386: 0.089 +virtual: 0.065 +permissions: 0.063 +socket: 0.059 +KVM: 0.053 +VMM: 0.047 +PID: 0.041 +user-level: 0.033 +TCG: 0.019 +x86: 0.013 +files: 0.006 +-------------------- +arm: 0.997 +debug: 0.997 +hypervisor: 0.375 +kernel: 0.324 +register: 0.256 +virtual: 0.080 +performance: 0.061 +architecture: 0.056 +peripherals: 0.047 +user-level: 0.047 +assembly: 0.029 +semantic: 0.021 +device: 0.014 +boot: 0.010 +files: 0.007 +graphic: 0.004 +TCG: 0.002 +permissions: 0.002 +risc-v: 0.002 +PID: 0.002 +VMM: 0.001 +network: 0.001 +mistranslation: 0.001 +KVM: 0.001 +ppc: 0.000 +socket: 0.000 +vnc: 0.000 +i386: 0.000 +x86: 0.000 + +SIGSEGV when reading ARM GIC registers through GDB stub diff --git a/results/classifier/zero-shot/118/semantic-arm/1704658 b/results/classifier/zero-shot/118/semantic-arm/1704658 new file mode 100644 index 000000000..5676fa740 --- /dev/null +++ b/results/classifier/zero-shot/118/semantic-arm/1704658 @@ -0,0 +1,116 @@ +semantic: 0.866 +graphic: 0.865 +performance: 0.843 +assembly: 0.827 +debug: 0.826 +PID: 0.821 +virtual: 0.820 +device: 0.819 +permissions: 0.814 +arm: 0.811 +architecture: 0.802 +register: 0.788 +socket: 0.783 +hypervisor: 0.772 +files: 0.769 +user-level: 0.769 +network: 0.759 +peripherals: 0.758 +KVM: 0.756 +ppc: 0.754 +kernel: 0.753 +boot: 0.739 +TCG: 0.717 +vnc: 0.715 +VMM: 0.701 +risc-v: 0.686 +i386: 0.661 +mistranslation: 0.595 +x86: 0.574 +-------------------- +user-level: 0.963 +x86: 0.293 +debug: 0.133 +virtual: 0.124 +files: 0.120 +TCG: 0.117 +register: 0.019 +PID: 0.016 +semantic: 0.016 +architecture: 0.011 +i386: 0.010 +device: 0.008 +network: 0.004 +assembly: 0.004 +hypervisor: 0.004 +permissions: 0.003 +VMM: 0.003 +socket: 0.003 +performance: 0.003 +vnc: 0.003 +peripherals: 0.002 +boot: 0.002 +KVM: 0.002 +graphic: 0.001 +kernel: 0.001 +risc-v: 0.001 +ppc: 0.001 +mistranslation: 0.001 +arm: 0.001 + +O_CLOEXEC not handled in dup3 system call in user mode + +In qemu user mode, for hppa and sparc64 targets, the parameter of the dup3 is not passed correctly when it contains the O_CLOEXEC flag. + +When the attached program runs, the expected output is: +errno=9=EBADF + +How to reproduce on hppa: +- Compile the program: hppa-linux-gnu-gcc-5 -O -Wall -static testdup3.c -o testdup3-hppa +- Set environment variables for running qemu-hppa. +- ~/inst-qemu/2.9.0/bin/qemu-hppa testdup3-hppa +errno=22=EINVAL +testdup3.c:54: assertion 'errno == EBADF' failed + +How to reproduce on sparc64: +- Compile the program: sparc64-linux-gnu-gcc-5 -O -Wall -static testdup3.c -o testdup3-sparc64 +- Set environment variables for running qemu-sparc64. +- ~/inst-qemu/2.9.0/bin/qemu-sparc64 testdup3-sparc64 +errno=22=EINVAL +testdup3.c:54: assertion 'errno == EBADF' failed + + + + + + + +I see this bug for hppa, sparc64. +I don't see it for m68k, mips, mips64, powerpc, powerpc64. +Most likely because the binary values of O_CLOEXEC on hppa and sparc64 are different than on other platforms. Looking in the glibc source code: + +$ grep -r 'define.*O_CLOEXEC' glibc +glibc/bits/fcntl.h:# define O_CLOEXEC 0x00400000 /* Set close_on_exec. */ +glibc/sysdeps/mach/hurd/bits/fcntl.h:# define O_CLOEXEC 0x00400000 /* Set FD_CLOEXEC. */ +glibc/sysdeps/unix/sysv/linux/sparc/bits/fcntl.h:#define __O_CLOEXEC 0x400000 /* Set close_on_exit. */ +glibc/sysdeps/unix/sysv/linux/bits/fcntl-linux.h:# define __O_CLOEXEC 02000000 +glibc/sysdeps/unix/sysv/linux/bits/fcntl-linux.h:# define O_CLOEXEC __O_CLOEXEC /* Set close_on_exec. */ +glibc/sysdeps/unix/sysv/linux/hppa/bits/fcntl.h:#define __O_CLOEXEC 010000000 /* Set close_on_exec. */ +glibc/sysdeps/unix/sysv/linux/microblaze/bits/fcntl.h:#define __O_CLOEXEC 02000000 /* Set close_on_exec. */ +glibc/sysdeps/unix/sysv/linux/alpha/bits/fcntl.h:#define __O_CLOEXEC 010000000 /* Set close_on_exec. */ +glibc/sysdeps/nacl/bits/fcntl.h:# define O_CLOEXEC 02000000 /* Set close_on_exec. */ + +So, what's missing is probably that the O_CLOEXEC of the target platform gets mapped to O_CLOEXEC of the host platform, during the dup3 system call emulation. + +The behaviour in qemu-2.10 is the same as in qemu-2.9. + +The behaviour in qemu-2.11 is the same as in qemu-2.9. + +Should be fixed by http://patchwork.ozlabs.org/patch/849226/ + + +Fix has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=10fa993aae539fa8d0da1d + +Confirmed: It's fixed in qemu-2.12. + diff --git a/results/classifier/zero-shot/118/semantic-arm/1809546 b/results/classifier/zero-shot/118/semantic-arm/1809546 new file mode 100644 index 000000000..cad50f359 --- /dev/null +++ b/results/classifier/zero-shot/118/semantic-arm/1809546 @@ -0,0 +1,137 @@ +semantic: 0.913 +debug: 0.906 +kernel: 0.877 +performance: 0.875 +user-level: 0.870 +permissions: 0.867 +arm: 0.866 +device: 0.860 +boot: 0.852 +assembly: 0.850 +graphic: 0.848 +register: 0.845 +VMM: 0.845 +peripherals: 0.839 +architecture: 0.839 +risc-v: 0.832 +network: 0.811 +PID: 0.807 +hypervisor: 0.802 +virtual: 0.797 +ppc: 0.779 +mistranslation: 0.754 +TCG: 0.742 +vnc: 0.735 +files: 0.732 +socket: 0.612 +KVM: 0.608 +x86: 0.473 +i386: 0.388 +-------------------- +arm: 0.987 +assembly: 0.979 +virtual: 0.462 +register: 0.123 +debug: 0.115 +kernel: 0.058 +peripherals: 0.042 +network: 0.042 +files: 0.031 +TCG: 0.023 +semantic: 0.020 +device: 0.020 +hypervisor: 0.015 +user-level: 0.010 +PID: 0.008 +socket: 0.006 +performance: 0.006 +VMM: 0.006 +ppc: 0.005 +risc-v: 0.005 +vnc: 0.005 +architecture: 0.004 +permissions: 0.003 +boot: 0.003 +x86: 0.003 +graphic: 0.002 +i386: 0.001 +KVM: 0.001 +mistranslation: 0.001 + +Writing a byte to a pl011 SFR overwrites the whole SFR + +The bug is present in QEMU 2.8.1 and, if my analysis is correct, also on master. + +I first noticed that a PL011 UART driver, which is fine on real hardware, fails to enable the RX interrupt in the IMSC register when running in QEMU. However, the problem only comes up if the code is compiled without optimizations. I think I've narrowed it down to a minimal example that will exhibit the problem if run as a bare-metal application. + +Given: + +pl011_addr: .word 0x10009000 + +The following snippet will be problematic: + + ldr r3, pl011_addr + ldrb r2, [r3, #0x38] // IMSC + mov r2, #0 + orr r2, r2, #0x10 // R2 == 0x10 + strb r2, [r3, #0x38] // Whole word reads correctly after this + ldrb r2, [r3, #0x39] + mov r2, #0 + strb r2, [r3, #0x39] // Problem here! Overwrites offset 0x38 as well + +After the first strb instruction, which writes to 0x10009038, everything is fine. It can be seen in the QEMU monitor: + +(qemu) xp 0x10009038 +0000000010009038: 0x00000010 + +After the second strb instruction, the write to 0x10009039 clears the entire word: + +(qemu) xp 0x10009038 +0000000010009038: 0x00000000 + +QEMU command-line, using the vexpress-a9 which has the PL011 at 0x10009000: + +qemu-system-arm -S -M vexpress-a9 -m 32M -no-reboot -nographic -monitor telnet:127.0.0.1:1234,server,nowait -kernel pl011-sfr.bin -gdb tcp::2159 -serial mon:stdio + +Compiling the original C code with optimizations makes the driver work. It compiles down to assembly that only does a single write: + + ldr r3, pl011_addr + mov r2, #0x10 + str r2, [r3, #0x38] + +Attached is the an assembly file, and linkscript, that shows the problem, and also includes the working code. + +I haven't debugged inside of QEMU itself but it seems to me that the problem is in pl011_write in pl011.c - the functions looks at which offset is being written, and then writes the entire SFR that offset falls under, which means that changing a single byte will change the whole SFR. + + + +Adding the link script. + +Yes, our PL011 implementation assumes that you only ever access the 32-bit registers with full width 32-bit word reads and writes. Don't try to do byte accesses to them. The PL011 data sheet doesn't specifically say that partial-width accesses to registers are permitted, so I think that trying to access offset 0x39 falls under the general note in section 3.1 that attempting to access reserved or unused address locations can result in unpredictable behaviour. + +You need to make sure you write your C code in a manner which enforces that accesses to device registers are done as single 32-bit accesses, and the compiler does not silently break them down into multiple reads and writes, or you will be in for a lot of pain trying to figure out what is going on if the compiler ever does it with registers that are write-to-clear or similar behaviour. Linux, for instance, does this by having readl() and writel() functions that end up doing inline asm of ldr/str instructions. + + +Thanks for the response. + +I don't think section 3.1 applies to 8-bit accesses. That is specifically about reserved locations, and neither offset 0x38 nor 0x39 are reserved, so I think it's a matter of whether 32-bit access is required or not. + +From what I usually see in ARM documentation, 32-bit access is explicitly mentioned when required. For the PL011, it's mentioned for the UARTPeriphID_n registers, for instance. In many other cases access size depends on the implementation and the corresponding memory mapping of that implementation. + +I understand that *in practice* you should ensure single-access writes unless doing otherwise is explicitly allowed. However, in cases like the PL011 it seems ambiguous whether that is actually required, so it seems like the best choice would be to explicitly document it for the QEMU implementation. That would save some guesswork. + +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 please 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/semantic-arm/1812091 b/results/classifier/zero-shot/118/semantic-arm/1812091 new file mode 100644 index 000000000..07bf87b53 --- /dev/null +++ b/results/classifier/zero-shot/118/semantic-arm/1812091 @@ -0,0 +1,123 @@ +semantic: 0.884 +virtual: 0.880 +graphic: 0.879 +debug: 0.869 +permissions: 0.862 +register: 0.858 +device: 0.845 +performance: 0.842 +peripherals: 0.839 +hypervisor: 0.837 +user-level: 0.833 +TCG: 0.828 +architecture: 0.825 +network: 0.824 +files: 0.823 +VMM: 0.816 +PID: 0.814 +arm: 0.812 +vnc: 0.811 +boot: 0.809 +assembly: 0.808 +kernel: 0.796 +ppc: 0.780 +KVM: 0.771 +risc-v: 0.764 +socket: 0.739 +i386: 0.689 +mistranslation: 0.642 +x86: 0.634 +-------------------- +arm: 0.947 +debug: 0.915 +architecture: 0.072 +semantic: 0.056 +files: 0.036 +virtual: 0.020 +register: 0.020 +user-level: 0.015 +kernel: 0.012 +PID: 0.011 +hypervisor: 0.011 +assembly: 0.010 +TCG: 0.008 +KVM: 0.002 +performance: 0.002 +socket: 0.002 +boot: 0.002 +device: 0.002 +network: 0.002 +peripherals: 0.002 +permissions: 0.002 +vnc: 0.001 +VMM: 0.001 +graphic: 0.001 +risc-v: 0.000 +mistranslation: 0.000 +i386: 0.000 +x86: 0.000 +ppc: 0.000 + +gdbstub memory accesses performed with wrong attributes + +Qemu-commit: b2f7c27f56bf1116ebb7848c75914aa7c5d6a040 + + +The ARMv8-M architecture (with security extensions) contains a SAU, the Security Attribution Unit. After booting the mps2-an505 and immediately halting (`-S`), I attempt to read the SAU_TYPE register, located at 0xE000EDD4, using gdb (x 0xE000EDD4). The returned value is 0, while the expected value is 8 (number of regions). + +On further investigation, it seems that `attrs.secure` is set to false (armv7m_nvic.c - nvic_readl, line 1167). Commenting out the check will return the correct value. + +As the CPU should be in 'secure' mode after reset, I think this behavior is wrong. + +Steps to reproduce: +Example code that loads an endless loop into the beginning of secure memory: https://github.com/ajblane/armv8m-hello + +Commandline: qemu-system-arm -machine mps2-an505 -cpu cortex-m33 \ + -m 4096 \ + -nographic -serial mon:stdio \ + -kernel $(IMAGE) -s -S + +Attach with arm-none-eabi-gdb, and run x 0xE000EDD4. + +This is not an issue with the CPU emulation, it is a bug in the gdb memory read/write path, which currently effectively always does its accesses as nonsecure. The CPU itself is correctly coming out of reset in secure mode and will be able to read the correct value of the register. + +I suspect that the following change will fix this: +diff --git a/exec.c b/exec.c +index 6e875f0640a..2f0f40b0be6 100644 +--- a/exec.c ++++ b/exec.c +@@ -3881,12 +3881,10 @@ int cpu_memory_rw_debug(CPUState *cpu, target_ulong addr, + phys_addr += (addr & ~TARGET_PAGE_MASK); + if (is_write) { + address_space_write_rom(cpu->cpu_ases[asidx].as, phys_addr, +- MEMTXATTRS_UNSPECIFIED, +- buf, l); ++ attrs, buf, l); + } else { + address_space_rw(cpu->cpu_ases[asidx].as, phys_addr, +- MEMTXATTRS_UNSPECIFIED, +- buf, l, 0); ++ attrs, buf, l, 0); + } + len -= l; + buf += l; + + +I'll test it later today and send it as a proper patch if it works. + + +Hello Peter and thanks a lot for your quick response. + +I have tested the patch and it seems to work! Looks like my testing code was buggy, apologies for the inaccurate bug description. + +Thanks, +Thomas + +Patch sent to list: + +https://patchwork.ozlabs.org/patch/1026664/ + + +This fix is now in git master and will be in the upcoming 4.0 QEMU release. + + diff --git a/results/classifier/zero-shot/118/semantic-arm/714 b/results/classifier/zero-shot/118/semantic-arm/714 new file mode 100644 index 000000000..51dacda8e --- /dev/null +++ b/results/classifier/zero-shot/118/semantic-arm/714 @@ -0,0 +1,103 @@ +semantic: 0.914 +arm: 0.888 +ppc: 0.810 +graphic: 0.775 +user-level: 0.767 +performance: 0.751 +device: 0.697 +vnc: 0.667 +risc-v: 0.651 +permissions: 0.639 +architecture: 0.617 +kernel: 0.616 +assembly: 0.487 +i386: 0.486 +mistranslation: 0.482 +socket: 0.476 +VMM: 0.440 +x86: 0.416 +network: 0.387 +PID: 0.370 +TCG: 0.359 +debug: 0.349 +register: 0.347 +hypervisor: 0.332 +files: 0.302 +peripherals: 0.287 +boot: 0.277 +KVM: 0.188 +virtual: 0.094 +-------------------- +arm: 0.948 +user-level: 0.751 +TCG: 0.203 +files: 0.140 +virtual: 0.125 +debug: 0.094 +PID: 0.019 +register: 0.012 +device: 0.011 +semantic: 0.007 +performance: 0.004 +architecture: 0.003 +network: 0.002 +boot: 0.002 +graphic: 0.002 +socket: 0.002 +peripherals: 0.002 +assembly: 0.001 +permissions: 0.001 +hypervisor: 0.001 +risc-v: 0.001 +VMM: 0.001 +mistranslation: 0.001 +kernel: 0.000 +KVM: 0.000 +vnc: 0.000 +ppc: 0.000 +x86: 0.000 +i386: 0.000 + +Command line arguments are not passed correctly with user-space semihosting +Description of problem: +The emulated process always receives a value of 1 for `argc`, with `argv[0]` returning seemingly random characters (in Ubuntu packaged qemu 5.2), but correlating with command-line input (output below from master built qemu 6.1): +``` +$ qemu-arm -cpu cortex-m7 ./a.out 123 test +argc: 1 +argv: + - @@@ + +$ qemu-arm -cpu cortex-m7 ./a.out +argc: 1 +argv: + [0] @ +``` +Steps to reproduce: +1. Compile the following program with [ARM embedded toolchain](https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads): +```cpp +#include <iostream> + +int main(int argc, char* argv[]) { + std::cout << "argc: " << argc << "\n"; + std::cout << "argv: \n"; + + for (int i = 0; i < argc; i++) + std::cout << " [" << i << "] " << argv[i] << "\n"; + return 0; +} +``` + +``` +$ $CXX --version +arm-none-eabi-g++ (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release) +Copyright (C) 2020 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + +$ $CXX main.cpp --specs=rdimon.specs -mcpu=cortex-m7 +``` + +2. Run in user-space (semihosted): +``` +$ qemu-arm -cpu cortex-m7 ./a.out +``` |