On 1 March 2016 at 13:00, Jakob Bohm <jb-gnumli...@wisemo.com> wrote: > As an alternative, could it be useful to look beyond the current > glibc code and see if there is a way for qemu-user to provide the > full set of Linux syscall provided facilities (including signals > and calls), without having to reserve some for itself. The > classic test is of cause to nest qemu-user under itself to > infinite depth using the same pair of qemu-user binaries > repeatedly without them knowing their own nesting depth.
This is possible in theory, but you basically have to ditch the idea of linking against glibc, which would be enormously painful. This is how valgrind does things, which gives it much more control. But since QEMU isn't a special purpose user-mode emulation codebase it would be really awkward -- much of our system emulation assumes and makes heavy use of not just glibc but also glib and other libraries. > For example, qemu-user could have a SIGSETXID handler which both > caters to the internal needs of qemu and its libraries but also > forwards the signal to any guest handlers (installed or default) > for that same signal. QEMU can't register a SIGSETXID handler for its own use, because glibc refuses to let you do that. There's a comment in the code which notes that it might be possible to multiplex some guest signals onto one host signal, which would let the guest use the currently inaccessible SIGRTMAX. thanks -- PMM
