qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Bug 1042388] Re: qemu: Unsupported syscall: 257 (timer


From: Peter Maydell
Subject: Re: [Qemu-devel] [Bug 1042388] Re: qemu: Unsupported syscall: 257 (timer_create)
Date: Sat, 9 Aug 2014 14:51:38 +0100

On 9 August 2014 07:15, Erik de Castro Lopo <address@hidden> wrote:
> Unfortunately the test case @pittit submitted is far harder to support
> than the original test case. In this case the timer_create() syscall
> gets passed pointers to functions and data in the target's address space
> and I have not figured out how to handle that yet.

Didn't we discuss this on the list a while back? You're confusing
the libc API with the kernel syscall API here -- the kernel definitely
does not take a pointer to a function to call here. (The timer_create
manpage explicitly says that the SIGEV_THREAD functionality
is implemented in the C library, not the kernel.) You can see
this if you strace it:

clone(child_stack=0xb76e5494,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0xb76e5bd8, {entry_number:6, base_addr:0xb76e5b70,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1},
child_tidptr=0xb76e5bd8) = 12666
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
futex(0xb76d324c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
timer_create(CLOCK_REALTIME, {0x984b098, 32, SIGEV_THREAD_ID,
{12666}}, {0x1}) = 0
timer_settime(0x1, 0, {it_interval={0, 0}, it_value={0, 50000000}}, NULL) = 0

Under the hood libc is creating a new thread with clone, and
what the timer_create() syscall gets passed is a struct including
the thread ID to be sent a signal when the timer expires (here
that's 12666).

So all you need to do is support SIGEV_THREAD_ID,
which I think doesn't require much more than copying
across the thread ID struct field.

(On the other hand that does mean that all programs which
use SIGEV_THREAD are by definition multithreaded, which
puts them into "this isn't supported" territory because of our
well known and longstanding threading issues.)

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]