[parisc-linux] Program counter from sigcontext, constructurs and -fPIC

[Boehm, Hans]

Thanks to all the help, my profiling code seems to be much healthier now after:

1) Switching to a machine with a 2.4.20-pa28 kernel and gcc 3.2.
2) Discarding the privilege level bits from the program counter value.
3) Adding 24 bytes to the struct sigcontext pointer (?) passed as a third argument to the signal handler. (!)

Needless to say, I'm still a bit concerned about (3).  Why does the third argument to the signal handler appear to point 24 bytes BEFORE the sigcontext structure?  Does it actually point at a bigger structure?  Is the third argument to a signal handler really not a pointer to sigcontext?  Did struct sigcontext change recently, so that I'm dealing with a version mismatch?

With the 24 bytes added, I clearly get the right program counter values.  I also seem to get the right general register values.

Thanks for any insight.

Hans

> -----Original Message-----
> From: Boehm, Hans 
> Sent: Friday, April 25, 2003 12:40 PM
> To: 'Carlos O'Donell'
> Cc: 'parisc-linux@lists.parisc-linux.org'; Boehm, Hans
> Subject: RE: [parisc-linux] Program counter from sigcontext,
> constructurs and -fPIC
> 
> 
> > -----Original Message-----
> > From: Carlos O'Donell [mailto:carlos@baldric.uwo.ca]
> > 
> > Hans,
> > 
> > What code are you porting? :)
> It's a new, currently rather simple, but thread-compatible, 
> purely user-level, profiler.  It includes some infrastructure 
> for using hardware atomic operations in reasonably portable 
> ways.  Need less to say, PA-RISC makes a wonderful test case.
> > 
> > > 1) I need to retrieve the pc value from the sigcontext 
> > structure passed to a timer signal handler.  In an earlier 
> > message, Paul Bame pointed me at sc_iaoq.  After a bit more 
> > reading, my conclusion was that sc_iaoq[0] should be a 
> > reasonable value to use as a sampled pc.  However I have been 
> > unable to see anything reasonable in that slot (or sc_iaoq[1] 
> > for that matter).  Presumably a struct sigcontext pointer is 
> > always passed as the third parameter to a signal handler?  
> > And it's filled in for timer interrrupts?  What does profil() 
> > do?  (I tried to read the code, but it's hard to trace 
> > through all the configuration stuff.)
> > 
> > A. What kernel are you using?
> 2.4.17-64 on spe170.testdrive.hp.com.
> >  
> > The reason I ask is that 64-bit kernels return broken sigcontext
> > pointers (for now it stuffs 64-bit values into a 32-bit 
> values within
> > the sigcontext, rather it should take into account the fact that
> > userspace or the calling threads personality is 32-bit and 
> > truncate the
> > register values).
> It sounds like that's the problem here.  Thanks.  
> > 
> > What is there to understand about profil()? Based on your PC it uses
> > modular arithmetic (the shift, scale, and division) to track 
> > on a coarse
> > scale which parts of your code are being executed.
> Once you get the PC in the signal handler, that's easy.  It 
> sounds like getting the PC from a signal handler from a 
> 32-bit executable on a 64-bit kernel is currently impossible? 
>  I should probably focus on 64-bit executables?  Or does 
> profil() have a way to get around the problem?
> > 
...