Version-Release number of selected component (if applicable): glibc-2.27.9000-42.fc29.i686 valgrind-3.13.0-24.fc29.i686 Steps to Reproduce: 1. mock -r fedora-rawhide-i386 --init 2. mock -r fedora-rawhide-i386 --install valgrind 3. mock -r fedora-rawhide-i386 --chroot 'valgrind /usr/bin/true' Actual results: --25050-- WARNING: unhandled x86-linux syscall: 384 --25050-- You may be able to write your own handler. --25050-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --25050-- Nevertheless we consider this a bug. Please report --25050-- it at http://valgrind.org/support/bug_reports.html. Additional info: This breaks build of curl on i686: https://koji.fedoraproject.org/koji/taskinfo?taskID=28733457
That is arch_prctl which should be handled. But only tested on x86_64.
That is weird. How did that get into i386? arch_prctl (2) says: arch_prctl() is supported only on Linux/x86-64 for 64-bit programs currently.
No idea but it seems to happen with all dynamically linked executables and also when explicitly running the dynamic linker itself: $ mock -r fedora-rawhide-i386 --chroot 'valgrind /lib/ld-linux.so.2' [...] ==25237== Command: /lib/ld-linux.so.2 ==25237== --25237-- WARNING: unhandled x86-linux syscall: 384 --25237-- You may be able to write your own handler. --25237-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --25237-- Nevertheless we consider this a bug. Please report --25237-- it at http://valgrind.org/support/bug_reports.html. Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...] [...]
Apparently it was recently added: commit 79170fda313ed5be2394f87aa2a00d597f8ed4a1 Author: Kyle Huey <me> Date: Mon Mar 20 01:16:24 2017 -0700 x86/syscalls/32: Wire up arch_prctl on x86-32 Hook up arch_prctl to call do_arch_prctl() on x86-32, and in 32 bit compat mode on x86-64. This allows to have arch_prctls that are not specific to 64 bits. On UML, simply stub out this syscall.
(In reply to Kamil Dudka from comment #3) > No idea but it seems to happen with all dynamically linked executables and > also when explicitly running the dynamic linker itself: > > $ mock -r fedora-rawhide-i386 --chroot 'valgrind /lib/ld-linux.so.2' > [...] > ==25237== Command: /lib/ld-linux.so.2 > ==25237== > --25237-- WARNING: unhandled x86-linux syscall: 384 > --25237-- You may be able to write your own handler. > --25237-- Read the file README_MISSING_SYSCALL_OR_IOCTL. > --25237-- Nevertheless we consider this a bug. Please report > --25237-- it at http://valgrind.org/support/bug_reports.html. > Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...] > [...] Yes that makes sense. This was recently fixed for x86_64. https://bugzilla.redhat.com/show_bug.cgi?id=1608824 I'll make a similar fix fir i386. I am surprised the glibc build got past its valgrind self-test though.
(In reply to Mark Wielaard from comment #5) > I am surprised the glibc build got past its valgrind self-test though. This was because it was "just" a Warning. But it is an annoying warning. So I'll fix it my explicitly recongizing arch_prctl on i386, but returning ENOSYS. Which is fine, because glibc interprets that as no CET support. Which is precisely what we want under valgrind.
Thanks for the quick fix! I can confirm that valgrind-3.13.0-25.fc29 works as expected and curl now builds successfully on i686, too.