/usr/lib/gcrt1.o on RH 7.2
Dear all,
Recently, I have been using RH 7.2 on ia64. Then I noticed that /usr/lib/gcrt1.o is wrong because I could not get result of gpof correctly. When some of programs are compild with -p switch and run them. After that, I wanted to confirm the infomation by profiler using gprof command, but gprof could not run correctly, it gives me wrong result or nothing display or illegal instrcution.
Does anyone already have any patches or any good idea?
Signature · 4 lines
End of my email -- Yours faithfully, Hideki Yamamoto (V).v.(V) # Empowered by Innovation
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Hideki Yamamoto
Hideki> Recently, I have been using RH 7.2 on ia64. Then I noticed Hideki> that /usr/lib/gcrt1.o is wrong because I could not get Hideki> result of gpof correctly. When some of programs are compild Hideki> with -p switch and run them. After that, I wanted to confirm Hideki> the infomation by profiler using gprof command, but gprof Hideki> could not run correctly, it gives me wrong result or nothing Hideki> display or illegal instrcution.
Hideki> Does anyone already have any patches or any good idea?
I haven't tried profiling on Red Hat recently, but in general, gprof-based profiling does work. I did try on Debian just a few days ago and it worked great.
--david
Dear David,
Let me know glibc version in your site which you did try.
I mean that profiling on RH 7.1 worked file, but it does not work on RH 7.2.
I think that this issue is caused by /usr/lib/gcrt1.o based on glibc-2.2.4.
After I found out this issue, I tried to use gcrt1.o
based on glibc-2.2.3 instead of gcrt1.o based on glibc-2.2.4.
It works fine. but I am afraid that this way gives a
bad effect to another programs. I mean that I do not know how /usr/lib/gcrt1.o is used or which program use /usr/lib/glibc1.o without profiling program made by -p.
End of my email
--
Yours faithfully,
Hideki Yamamoto (V).v.(V) # Empowered by Innovation
At Fri, 21 Jun 2002 11:41:49 -0700,
Quoted 19 lines · David Mosberger
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines · Hideki Yamamoto
Hideki> Recently, I have been using RH 7.2 on ia64. Then I noticed Hideki> that
/usr/lib/gcrt1.ois wrong because I could not get Hideki> result of gpof correctly. When some of programs are compild Hideki> with -p switch and run them. After that, I wanted to confirm Hideki> the infomation by profiler using gprof command, but gprof Hideki> could not run correctly, it gives me wrong result or nothing Hideki> display or illegal instrcution.Hideki> Does anyone already have any patches or any good idea?
I haven't tried profiling on Red Hat recently, but in general, gprof-based profiling does work. I did try on Debian just a few days ago and it worked great.
--david
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Hideki Yamamoto
Hideki> Let me know glibc version in your site which you did try.
I was just using the latest glibc package from the Debian "testing" archive.
--david
Quoted 9 lines
Hideki> the infomation by profiler using gprof command, but gprof Hideki> could not run correctly, it gives me wrong result or nothing Hideki> display or illegal instrcution.
Hideki> Does anyone already have any patches or any good idea?
I haven't tried profiling on Red Hat recently, but in general, gprof-based profiling does work. I did try on Debian just a few days ago and it worked great.
At least on Debian, if the application is linked against pthread then compiling with profiling does not work. The resulting binary will die with a SIGILL on startup. You don't need to actually call any pthread functions, just linking pthread is enough.
randolph
Signature · 3 lines
Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Randolph Chung
Randolph> At least on Debian, if the application is linked against Randolph> pthread then compiling with profiling does not work. The Randolph> resulting binary will die with a SIGILL on startup. You Randolph> don't need to actually call any pthread functions, just Randolph> linking pthread is enough.
Even if it's statically linked? Dynamically linked binaries do not work with gprof. I wasn't aware of any pthread-specific issues.
--david
Quoted 2 lines
Even if it's statically linked? Dynamically linked binaries do not work with gprof. I wasn't aware of any pthread-specific issues.
yup, static works. dynamic binaries not linked against pthread seems to work too...
randolph
Signature · 3 lines
Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/
This issue was the known bug.
Sorry for bothering all.
I deeply appreciate that Greg told me this issus has already issued in Feb.
http://gcc.gnu.org/ml/gcc-bugs/2002-02/msg00777.html
End of my email
--
Yours faithfully,
Hideki Yamamoto (V).v.(V) # Empowered by Innovation
Quoted 10 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines · Hideki Yamamoto
Hideki> Let me know glibc version in your site which you did try.
I was just using the latest glibc package from the Debian "testing" archive.
--david