|
From: Tom H. <to...@co...> - 2006-02-14 14:57:40
|
In message <43F...@wa...>
Eric Pouech <eri...@wa...> wrote:
> Tom Hughes wrote:
>
> > I think the correct solution to the trap number problem is to make
> > sure we propagate it from the original kernel delivered signal
> > frame to the one we create for the client program, but that is
> > slightly complicated. We would also need to fake something up when
> > we synthesise a signal.
>
> I didn't see any place where you get the trap-no from a rt signal
> handler on x86, or did I miss something ?
Well that's the point... The path for a normal signal that originates
from the kernel is like this:
- signal delivered to sync_signalhandler or async_signalhandler
- at this point we have a ucontext with a trapno in it
- signal passed to deliver_signal
- here the ucontext is lost as it is not passed in
- push_signal_frame called to construct frame for client program
- platform specific VG_(sigframe_create) called to construct frame
- build_rt_sigframe or build_sigframe called
- synth_ucontext called
- here we need to store the trap number in the created ucontext
What you proposed is that synth_ucontext should try and guess the
trap number from the signal number and code.
I am suggesting that the original kernel ucontext should be propagated
down through that call stack so that synth_ucontext can take the
original kernel supplied trap number from it which is guaranteed to
be accurate.
The only problem is that deliver_signal is called from other places
like synth_fault_common, synth_sigill and synth_sigtrap which would
have to invent a ucontext with an appropriate trap number or something.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|