Hi Stefane,

My apologies, I didn't check the other examples. Once upon a time I
looked and they all were globals...that's what I get for not checking
the facts.

Phil


On Thu, 2007-01-25 at 06:49 -0800, Stephane Eranian wrote:
> Phil,
> 
> On Wed, Jan 17, 2007 at 07:32:03PM +0100, Philip J. Mucci wrote:
> > 
> > Another problem I had spotted was with self notification, but that
> > didn't show up in the libpfm test suite, In PAPI I use the sigpoll.si_fd
> > value from the signal handler to find out which FD I should read() the
> > data from. If you look in notify_self, you'll see that Stefane cheats
> > and stores it in a global variable. ;-) (BTW, Stefane this should be
> > changed to read it from the context...it's more useful to users that way
> > and tests more of the system) Now, I'm using a 64 bit 2.6.15 kernel with
> > 64 bit user land and the si_fd was zero according to the sig handler.
> > Inspecting the signal context indicated that there was an wrong offset
> > somewhere...because the correct FD was in the structure, just at an
> > offset I didn't expect.
> > 
> If you look at notify_self2.c, you'll have the example you are looking 
> for,i.e.,
> one that uses si_fd. Note that on some arch, you MUST set:
> 
>       sigaction.sa_flags   = SA_SIGINFO;
> 
> in order to have valid siginfo data, otherwise you'll get zeroes.
> 
> > I would recommend that on your system, you try digging out the si_fd
> > from the signal context and see if that value is 0 or if it is a valid
> > context. That would be a linux bug (maybe in the libc headers) and needs
> > to be fixed.
> > 
> One of the reasons why I have 3 notify_self examples is to show three 
> different
> ways of getting notification for yourself.
> 

_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/

Reply via email to