|
From: Eric P. <eri...@wa...> - 2006-02-14 13:28:23
|
Tom Hughes wrote: > 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. I didn't see any place where you get the trap-no from a rt signal handler on x86, or did I miss something ? A+ -- Eric Pouech |