Using -pg on hppa *is* broken
lamont,
I know you were looking for me regarding the use of '-pg' profiling in debian. It *is* broken, it's fixed on my experimental system thanks to a few patches from Randolph. I'm currently looking into sprof so I can profile glibc itself (not working currently).
The main issue was that the 'start' symbol needs to be canonicalized before passing on to the gmon routines. This requires entry.h to be modified. What does this *really* mean? It means that in general you need a gcc-3.3 runtime to have glibc work properly, the good news is that debian doesn't have to have a gcc-3.3 runtime since __c_f_f_c was backported for our gcc pacakges.
I need to coordinate with the debian-glibc people again to resync the patches required for hppa.
Cheers,
Carlos.
Quoted 2 lines
The main issue was that the 'start' symbol needs to be canonicalized before passing on to the gmon routines. This requires
entry.hto be
I still think that using __c_f_f_c for this special case is overkill.
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Quoted 2 lines
The main issue was that the 'start' symbol needs to be canonicalized before passing on to the gmon routines. This requires
entry.hto be
I still think that using __c_f_f_c for this special case is overkill.
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
[parisc-linux] Good news for glibc.
Quoted 4 lines · John David Anglin
Quoted 2 lines
The main issue was that the 'start' symbol needs to be canonicalized before passing on to the gmon routines. This requires
entry.hto beI still think that using
__c_f_f_cfor this special case is overkill.
What could we use?
Good news, I just fixed LD_PROFILE so I can actually check to see what functions take up too much time :) I think I inadvertently fixed it for ia64 too... what do ia64 people use to profile glibc?
c.
A tempting peek! :)
% cumulative self self total
time seconds seconds calls us/call us/call name 0.00 0.00 0.00 14000 0.00 cfree 0.00 0.00 0.00 6000 0.00 memset 0.00 0.00 0.00 2004 0.00 malloc 0.00 0.00 0.00 2003 0.00 flockfile 0.00 0.00 0.00 2003 0.00 funlockfile 0.00 0.00 0.00 2001 0.00 __cxa_finalize 0.00 0.00 0.00 1002 0.00 index 0.00 0.00 0.00 1000 0.00 __GI__dl_close 0.00 0.00 0.00 1000 0.00 __GI__dl_open 0.00 0.00 0.00 1000 0.00 printf 0.00 0.00 0.00 1000 0.00 puts 0.00 0.00 0.00 1000 0.00 strlen 0.00 0.00 0.00 1 0.00 __libc_start_main 0.00 0.00 0.00 1 0.00 realloc 0.00 0.00 0.00 1 0.00 strrchr
[parisc-linux] Good news for glibc.
In reply to John David AnglinQuoted 4 lines · John David Anglin
Quoted 2 lines
The main issue was that the 'start' symbol needs to be canonicalized before passing on to the gmon routines. This requires
entry.hto beI still think that using
__c_f_f_cfor this special case is overkill.
What could we use?
Good news, I just fixed LD_PROFILE so I can actually check to see what functions take up too much time :) I think I inadvertently fixed it for ia64 too... what do ia64 people use to profile glibc?
c.
A tempting peek! :)
% cumulative self self total
time seconds seconds calls us/call us/call name 0.00 0.00 0.00 14000 0.00 cfree 0.00 0.00 0.00 6000 0.00 memset 0.00 0.00 0.00 2004 0.00 malloc 0.00 0.00 0.00 2003 0.00 flockfile 0.00 0.00 0.00 2003 0.00 funlockfile 0.00 0.00 0.00 2001 0.00 __cxa_finalize 0.00 0.00 0.00 1002 0.00 index 0.00 0.00 0.00 1000 0.00 __GI__dl_close 0.00 0.00 0.00 1000 0.00 __GI__dl_open 0.00 0.00 0.00 1000 0.00 printf 0.00 0.00 0.00 1000 0.00 puts 0.00 0.00 0.00 1000 0.00 strlen 0.00 0.00 0.00 1 0.00 __libc_start_main 0.00 0.00 0.00 1 0.00 realloc 0.00 0.00 0.00 1 0.00 strrchr