|
From: Tom H. <to...@co...> - 2006-02-13 23:53:39
|
In message <43F...@wa...>
Eric Pouech <eri...@wa...> wrote:
> Tom Hughes wrote:
>
> > > I dunno (I do have the same thoughts about it). My point was not to make
> > > a 100% accurate patch, but at least to show the areas that needed to be
> > > improved. IMO, the best solution would be not to ask for a RT signal
> > > handler if the user doesn't ask for (there's nothing to be done here,
> > > just passing the information), but it complicates a bit the signal
> > > handling code on V side.
> >
> > I'm not sure I understand what you mean there - regardless of what
> > sort of handler valgrind asks the kernel for it should always be
> > presenting the right sort (rt or non-rt) of signal frame to the
> > application's handler.
>
> I was talking about the sig handler valgrinds asks for to the kernel.
> IMO, if we want to get the mappings 100% right from the kernel, we
> should do something like:
> - if the user asks for a non rt sig handler, vg should ask for a non rt
> sig handler
> - if the user asks for a rt sig handler, vg should ask for a rt sig handler
> of course, that would duplicate all the sig handler code
I understand what you are suggesting, but why do you think we need to
do it? and what does it have to do with the trap number stuff?
The rt handlers are effectvely a superset of the non-rt ones so we
can always construct a valid non-rt signal frame based on an rt
signal frames supplied to us by the kernel, which is what we do.
In other words it should be transparent to the application running
under valgrind that valgrind is always asking the kernel for rt
signal frames. You seem to think that it is not transparent for
some reason?
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.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|