Re: [Valgrind-developers] adding system call support

[Tom H. <th...@cy...>]

In message <Pin...@sc...>
          Bob Friesenhahn <bfr...@si...> wrote:

> On Fri, 4 Jun 2004, Tom Hughes wrote:
> 
> >> The application code executed is:
> >>
> >>      struct sigevent event;
> >>      memset( &event, 0, sizeof( struct sigevent ) );
> >>      event.sigev_notify = SIGEV_THREAD;
> >>      event.sigev_notify_function = &timer_thread_handler;
> >>      event.sigev_value.sival_ptr = this;
> >>      timer_create( CLOCK_REALTIME, &event, &timer_id );
> >>
> >> where timer_thread_handler is a function, and timer_id is part of the
> >> enclosing C++ class.
> >
> > If timer_create is really a system call then how is that function
> > getting invoked - does the kernel invoke it asynchronously like a
> > signal handler? If so then addding support for that system is going
> > to be non-trivial and won't be as simple as adding a wrapper for
> > the call to vg_syscalls.c as you will have to teach valgrind how
> > to catch and emulate the callback.
> 
> I agree that SIGEV_THREAD support requires some sort of participation
> from the thread library.  However as I mentioned before, the timer
> callback thread doesn't ever get invoked with this kernel & threads
> implementation.  To make matters more complicated, we are using the
> LFS threads implementation.  I do know that signal-based notification
> does work.

I've looked at the librt code for timer_create now and it turns
our that for a SIGEV_THREAD event it actually installs it's own
signal handler then calls the system call for a SIGEV_SIGNAL event
and lets the signal handler trigger the running of the function.

So there shouldn't be much complication to the system call definition
as the system call only handles signal events.

Tom

-- 
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/