From: Jeff Dike <jdike@ka...> - 2002-07-16 04:00:24
> Next task: signals.
This involves some nasty trickery in order to construct signal frames without
having to know too much about them. This is going to involve getting frame.c
Let me know if you have any questions about this.
Great work so far, BTW.
From: Jeff Dike <jdike@ka...> - 2002-07-21 17:05:48
I've been meaning to correct what I said. frame.c is completely irrelevant
I'm taking advantage of the fact that the underlying OS is Linux, and using
the host's signal frames as templates for UML signal frames.
You need to construct Linux signal frames by hand since you won't have any
help from the host OS.
> Can you briefly describe how signal frames are constructed and
> delivered in uml ?
When a process has queued signals, handle_signal is called if one needs to
be delivered. It calls either setup_signal_stack_si or setup_signal_stack_sc,
depending on whether it's a SA_INFO signal or not (si == siginfo,
sc == sigcontext). Get _sc working first - SA_INFO is fairly rare.
Then we're in setup_signal_stack_sc, which takes a template frame that it
copied from the host, and fills it in. You'll need to hard-code the template
if you want to reuse this code. setup_signal_stack_sc has the template, and
it knows where within it the signal number, sigcontext struct, saved signal
mask, and restorer go. It copies the template onto the process stack, and
then fills in those slots with the current signal information.
Then, it changes the sp and ip in the process saved registers so that they
will be restored when the process re-enters userspace. The process will
thus find itself executing the signal handler.
> My feeling is that the signal frames should not
> change between uml on x86 and umlwin32 on x86, right?
Yes, that's right.
As you know, we are not using the host signal support for umlwin32. We are
also not using the tracing-thread/signals for implementing system calls
(LINE does this by providing an interrupt redirector instead).
So do we need to implement all the functions in frame.c ? Looks like
capture_stack and capture_signal_stack are required only for this and are
not used for delivering signals, is that correct?
Can you briefly describe how signal frames are constructed and delivered
in uml ? My feeling is that the signal frames should not change between
uml on x86 and umlwin32 on x86, right?
On Tue, 16 Jul 2002, Jeff Dike wrote:
> chandan@... said:
> > Next task: signals.
> This involves some nasty trickery in order to construct signal frames without
> having to know too much about them. This is going to involve getting frame.c
> Let me know if you have any questions about this.
> Great work so far, BTW.