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

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

[Boehm, Hans]

I have two questions arising from an attempt to port some profiling code to pa-risc.  Grant Grundler suggested I ask here.

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.)

2) If I mark a C function as a constructor function, and compile it with -fPIC, it seems to run before globals are properly accessible.  The retrieval of the address of a global through the global offset table seems to return a bad address and the access faults.  Are there known issues in this area?  (The offending function actually ends up in the main program, if that matters.)

Please cc: me in the reply.

Thanks.

Hans

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

[Carlos O'Donell]

Hans,

What code are you porting? :)

> 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?
 
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).

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.

> 2) If I mark a C function as a constructor function, and compile it with -fPIC, it seems to run before globals are properly accessible.  The retrieval of the address of a global through the global offset table seems to return a bad address and the access faults.  Are there known issues in this area?  (The offending function actually ends up in the main program, if that matters.)

B. Can we see the code?

c.

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

[Boehm, Hans]

> -----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?
> 
> > 2) If I mark a C function as a constructor function, and 
> compile it with -fPIC, it seems to run before globals are 
> properly accessible.  The retrieval of the address of a 
> global through the global offset table seems to return a bad 
> address and the access faults.  Are there known issues in 
> this area?  (The offending function actually ends up in the 
> main program, if that matters.)
> 
> B. Can we see the code?
> 
I haven't officially released it, since I wanted to make sure it at least passed its tests on HP Linux platforms.  I do have permission to release it, so I put a preliminary snapshot at http://hpl.hp.com/personal/Hans_Boehm/qprof/qprof-0.2.tar.gz (probably not its final location).

I believe "make check" works on X86/Itanium/Alpha, but not PA.  (Feedback on the code itself is of course also gratefully accepted.)  The only problem on PA should be running qprof_test.

Thanks.

Hans

Re: [parisc-linux] Program counter from sigcontext, constructurs

[John David Anglin]

> > > 2) If I mark a C function as a constructor function, and 
> > compile it with -fPIC, it seems to run before globals are 
> > properly accessible.  The retrieval of the address of a 
> > global through the global offset table seems to return a bad 
> > address and the access faults.  Are there known issues in 
> > this area?  (The offending function actually ends up in the 
> > main program, if that matters.)

I'm not aware of any.  All the libstdc++ test pass and this involves
running constructors in a shared library, so it would seem the PIC
register and got table must be setup.  Function pointer canonicalization
involves accessing the got table in some situations.  This can happen
in crtstuff.c which runs constructors.  Do you have a testcase?

It might be a linker issue.  There are some subtle issues with calling
PIC code that's not in a shared library.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

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

[Carlos O'Donell]

Hans,

> 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.

Cool. (Could you please make your MUA wrap lines at a reasonable length?).

> > A. What kernel are you using?
> 2.4.17-64 on spe170.testdrive.hp.com.

Needs updating :)
  
> 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?

64-bit executables don't exist in Linux .... I'm working on it, if you
want to get into the glibc port please talk to me off-list :)

64-bit kernels spill 64-bit values into the 32-bit values of the
sigcontext struct. Which means you get everything in the wrong place and
much larger than you expected. This _has_ to be fixed soon, perhaps I'll
look at this code next.

c. 

RE: [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?
> > 
...

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

[Carlos O'Donell]

> 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.

Why?

> 3) Adding 24 bytes to the struct sigcontext pointer (?) passed as a third argument to the signal handler. (!)

Are you still using a 64-bit kernel?

> 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?

What glibc version is installed? I made recent changes to mache the
userspace and kernel versions of sigcontext (now a machine context).
 
> With the 24 bytes added, I clearly get the right program counter values.  I also seem to get the right general register values.

How are you accessing this value? Can you generate a simple testcase
please?

c.

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

[Grant Grundler]

On Tue, Apr 29, 2003 at 05:30:28PM -0400, Carlos O'Donell wrote:
> > 3) Adding 24 bytes to the struct sigcontext pointer (?) passed as a third argument to the signal handler. (!)
> 
> Are you still using a 64-bit kernel?

no - he's using:
grundler@debian:~$ uname -a
Linux debian 2.4.20-pa28 #39 Wed Mar 12 19:24:25 PST 2003 parisc unknown
unknown GNU/Linux

It's possible the kernel-headers he's using aren't clean.
Just in case, can you tell me which ones he should be using?

> What glibc version is installed? I made recent changes to mache the
> userspace and kernel versions of sigcontext (now a machine context).

grundler@debian:~$ dpkg -l libc6\*
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  libc6          2.3.1-16       GNU C Library: Shared libraries and Timezone
un  libc6-bin      <none>         (no description available)
pn  libc6-dbg      <none>         (no description available)
ii  libc6-dev      2.3.1-16       GNU C Library: Development Libraries and Hea
...

grundler@debian:~$ ls -l /var/opt/LinuxCOE/Debian/pool/main/g/glibc/libc6-dev_2.3.1-*_hppa.deb
-rw-rw-r--    1 root     1176      2958496 Mar 22 12:02 /var/opt/LinuxCOE/Debian/pool/main/g/glibc/libc6-dev_2.3.1-16_hppa.deb
-rw-rw-r--    1 root     1176      2959794 Apr 21 06:47 /var/opt/LinuxCOE/Debian/pool/main/g/glibc/libc6-dev_2.3.1-17_hppa.deb


I'm ok with updating to -17 if you promise it won't do evil things
to my box. ;^)

thanks,
grant

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

[Carlos O'Donell]

g,

> no - he's using:
> grundler@debian:~$ uname -a
> Linux debian 2.4.20-pa28 #39 Wed Mar 12 19:24:25 PST 2003 parisc unknown
> unknown GNU/Linux

Perfect.
 
> It's possible the kernel-headers he's using aren't clean.
> Just in case, can you tell me which ones he should be using?

/usr/inlcude/asm/sigcontext.h should define it to be:

/* We will add more stuff here as it becomes necessary, until we know
   it works. */
struct sigcontext {
        unsigned long sc_flags;
        unsigned long sc_gr[32]; /* PSW in sc_gr[0] */
        unsigned long long sc_fr[32]; /* FIXME, do we need other state info? */
        unsigned long sc_iasq[2];
        unsigned long sc_iaoq[2];
        unsigned long sc_sar; /* cr11 */
};

Which is used to define an identical mcontext.

> ii  libc6          2.3.1-16       GNU C Library: Shared libraries and Timezone
> ii  libc6-dev      2.3.1-16       GNU C Library: Development Libraries and Hea

Perfect.

> I'm ok with updating to -17 if you promise it won't do evil things
> to my box. ;^)

Don't touch -17, the _Unwind_Find_FDE code broke and it's doing damage
to things like 'vi' ... *sigh* I haven't even looked into this (looks
like gcc/glibc clashes again).

c.

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

[Boehm, Hans]

The struct sigcontext seems to match the declarations I'm seeing and what dbx is seeing.

I think you should be able to reproduce the problem fairly simply by:

1) Downloading http://www.hpl.hp.com/personal/Hans_Boehm/qprof/qprof-0.2.tar.gz
2) Unpacking
3) "make qprof_test" with a recent gcc; this should only take a few seconds.  This doesn't use much of the source code, or uses it in only trivial ways.
4) gdb ./qprof_test
5) break PROF_pc_sample_list_handler; run
6) Look at the handler arguments, particularly the third one.

The corresponding sigaction call is also in prof_utils.c, the same file that contains the above function.  All of the relevant code is either in prof_utils.c and prof_main.c.

(If everything worked, this would report PC samples that are off by 3, since it doesn't contain the privilege level fix.)

Hans

> -----Original Message-----
> From: Carlos O'Donell [mailto:carlos@baldric.uwo.ca]
> Sent: Tuesday, April 29, 2003 5:31 PM
> To: Grant Grundler
> Cc: Boehm, Hans; 'parisc-linux@lists.parisc-linux.org'
> Subject: Re: [parisc-linux] Program counter from sigcontext,
> constructurs and -fPIC
> 
> 
> 
> g,
> 
> > no - he's using:
> > grundler@debian:~$ uname -a
> > Linux debian 2.4.20-pa28 #39 Wed Mar 12 19:24:25 PST 2003 
> parisc unknown
> > unknown GNU/Linux
> 
> Perfect.
>  
> > It's possible the kernel-headers he's using aren't clean.
> > Just in case, can you tell me which ones he should be using?
> 
> /usr/inlcude/asm/sigcontext.h should define it to be:
> 
> /* We will add more stuff here as it becomes necessary, until we know
>    it works. */
> struct sigcontext {
>         unsigned long sc_flags;
>         unsigned long sc_gr[32]; /* PSW in sc_gr[0] */
>         unsigned long long sc_fr[32]; /* FIXME, do we need 
> other state info? */
>         unsigned long sc_iasq[2];
>         unsigned long sc_iaoq[2];
>         unsigned long sc_sar; /* cr11 */
> };
> 
> Which is used to define an identical mcontext.
> 
> > ii  libc6          2.3.1-16       GNU C Library: Shared 
> libraries and Timezone
> > ii  libc6-dev      2.3.1-16       GNU C Library: 
> Development Libraries and Hea
> 
> Perfect.
> 
> > I'm ok with updating to -17 if you promise it won't do evil things
> > to my box. ;^)
> 
> Don't touch -17, the _Unwind_Find_FDE code broke and it's doing damage
> to things like 'vi' ... *sigh* I haven't even looked into this (looks
> like gcc/glibc clashes again).
> 
> c.
> 

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

[Grant Grundler]

On Tue, Apr 29, 2003 at 08:31:06PM -0400, Carlos O'Donell wrote:
...
> /* We will add more stuff here as it becomes necessary, until we know
>    it works. */
> struct sigcontext {
>         unsigned long sc_flags;
>         unsigned long sc_gr[32]; /* PSW in sc_gr[0] */
...

yes. exactly matches.

...
> Don't touch -17, the _Unwind_Find_FDE code broke and it's doing damage
> to things like 'vi' ... *sigh* I haven't even looked into this (looks
> like gcc/glibc clashes again).

ok. thanks for the warning.

Looks things are as good as they are going to get on that box for
the time being then.

thanks,
grant

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

[Joel Soete]

Hi,

>
>> ii  libc6          2.3.1-16       GNU C Library: Shared libraries and
Timezone
>> ii  libc6-dev      2.3.1-16       GNU C Library: Development Libraries
>and Hea
>
>Perfect.
>
>> I'm ok with updating to -17 if you promise it won't do evil things
>> to my box. ;^)
>
>Don't touch -17, the _Unwind_Find_FDE code broke and it's doing damage
>to things like 'vi' ... *sigh* I haven't even looked into this (looks
>like gcc/glibc clashes again).
>
Umm could this be why that my b2k crashed when compiling a kernel to test
a patch?

I just come back to libc6 2.3.1-16: the pb didn't occurs anymore. 
(I was a bit confused because just did it on a test 2.4.21-rc1 :) )

Thanks,
    Joel


---------------------------------
Vous surfez avec une ligne classique ?
Economisez jusqu'à 25% avec Tiscali Complete !
Offre spéciale : première année d'abonnement offerte.
... Plus d'info sur http://complete.tiscali.be

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

[Carlos O'Donell]

> >Don't touch -17, the _Unwind_Find_FDE code broke and it's doing damage
> >to things like 'vi' ... *sigh* I haven't even looked into this (looks
> >like gcc/glibc clashes again).
> >
> Umm could this be why that my b2k crashed when compiling a kernel to test
> a patch?

Quite possibly. If you can get a backtrace of the crash you'll se it die
inside _Unwind_Find_FDE in glibc.
 
I'm working on fixing this.

c.

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

[Grant Grundler]

On Tue, Apr 29, 2003 at 02:17:32PM -0700, Boehm, Hans wrote:
> 3) Adding 24 bytes to the struct sigcontext pointer (?) passed
>    as a third argument to the signal handler. (!)
...
> Is the third argument to a signal handler really not a pointer to sigcontext?

Yes - that seems to be the case.
Randolph found most of the answer in "Single Unix Specification"
(IEEE 1033.1-2001).  Third argument is "ucontext_t".

We counted 20 bytes (not 24) before the "struct sigcontext uc_mcontext;"
and thus still don't have a full explanation. Our best guess is some
misc padding is involved.

hth,
grant

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

[Joel Soete]

Carlos O'Donell wrote:

>>>Don't touch -17, the _Unwind_Find_FDE code broke and it's doing damage
>>>to things like 'vi' ... *sigh* I haven't even looked into this (looks
>>>like gcc/glibc clashes again).
>>>
>>>      
>>>
>>Umm could this be why that my b2k crashed when compiling a kernel to test
>>a patch?
>>    
>>
>
>Quite possibly. If you can get a backtrace of the crash you'll se it die
>inside _Unwind_Find_FDE in glibc.
>
I couldn't anymore check because unfortunately even after comming back 
to libc6 sub debian release -16 my b2k crashes severall times. The last 
time was badly in the middle of a apt-get dist-upgrade; this crash 
corrupt the root fs so that it isn't any more usable. I will try to 
recover it asap to check.

That said, I suspect more another hw pb (it is not the first time with 
this b2k model on which hp had already have to replace the cpu) or a bug 
into cd-ide driver (this is the only model I had the chance to test with 
this kind of feature).

> 
>I'm working on fixing this.
>
>  
>
Thanks for your attention,
    Joel

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

[Joel Soete]

Hi Carlos,

>
>That said, I suspect more another hw pb (it is not the first time with 
>this b2k model on which hp had already have to replace the cpu) or a bug
>
Definitely it must be a HW pb: I read back the very last pim info that I
grab with minicom I find:
...
Memory/IO Controller Error Analysis Information:

                 Occurs
...
        Runway Addr = 0xc13ff0 f0f000cd0a
...

Even thought this messages seems to be OS independant (PDC only IMHO?), I
will so come back to hpux with the hope that pb re-occurs and that I can
open a HW call neer HP.

Regards,
    Joel

---------------------------------
Vous surfez avec une ligne classique ?
Economisez jusqu'à 25% avec Tiscali Complete !
Offre spéciale : première année d'abonnement offerte.
... Plus d'info sur http://complete.tiscali.be