>> > The problem we see is that the system call numbers in qemus >> > unicore32/syscall_nr.h dont match what is linux mainline kernel. From >> the >> > toolchain linked, you seem to have kernel headers and syscall numbers >> > based on a custom 2.6.32 fork. If one builds unicore32 binaries based >> on >> > Linux 4.4 kernel headers, they will not work qemu. OTOH the binary >> built >> > with the toolchain you linked, would not work with linux 4.4. This >> > disparity is what we'd like to get fixed. > >> OK, I see. >> I'd send kernel-patches merge request to linus, but the patches hadn't >> be >> merged. >> I'll work on it. Hopefully it'll be done before mid Oct. > > This blocks some cleanup work in linux-user code. For example everyone has > moved over from epoll_wait to epoll_pwait. However, I can't remove the now > unneeded TARGET_NR_epoll_pwait, because nobody is keeping unicore32 > syscall > list upto date.
Yes, Unicore32 syscalls haven't been upgraded for several years, keeping the same as all along. Therefore, many new syscalls can't be used. > > I think we should temporarily disable the unicore32-linux-user target, and > re-enable it in be 2.8 softfreeze if the system calls get updated. Good point. Maybe, unicore32-linux-user could be re-enabled after both kernel and glibc getting updated. > > Riku > Thanks Riku. Xuetao
