[Linux-ia64] /usr/lib/gcrt1.o on RH 7.2

[Linux-ia64] /usr/lib/gcrt1.o on RH 7.2

[Hideki Yamamoto]

 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?

-- 
End of my email
--
Yours faithfully,
Hideki Yamamoto   (V).v.(V) # Empowered by Innovation

Re: [Linux-ia64] /usr/lib/gcrt1.o on RH 7.2

[David Mosberger]

>>>>> On Fri, 21 Jun 2002 23:21:35 +0900, "Hideki Yamamoto" <hideki@hpc.bs1.fc.nec.co.jp> said:

  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

Re: [Linux-ia64] /usr/lib/gcrt1.o on RH 7.2

[Hideki Yamamoto]

 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,
David Mosberger wrote:
> 
> >>>>> On Fri, 21 Jun 2002 23:21:35 +0900, "Hideki Yamamoto" <hideki@hpc.bs1.fc.nec.co.jp> said:
> 
>   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
> 

Re: [Linux-ia64] /usr/lib/gcrt1.o on RH 7.2

[David Mosberger]

>>>>> On Sat, 22 Jun 2002 15:16:15 +0900, "Hideki Yamamoto" <hideki@hpc.bs1.fc.nec.co.jp> said:

  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

Re: [Linux-ia64] /usr/lib/gcrt1.o on RH 7.2

[Randolph Chung]

>   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
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [Linux-ia64] /usr/lib/gcrt1.o on RH 7.2

[David Mosberger]

>>>>> On Sat, 22 Jun 2002 23:11:47 -0700, Randolph Chung <randolph@tausq.org> said:

  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

Re: [Linux-ia64] /usr/lib/gcrt1.o on RH 7.2

[Randolph Chung]

> 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
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [Linux-ia64] /usr/lib/gcrt1.o on RH 7.2

[Hideki Yamamoto]

 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

> 
> >>>>> On Sat, 22 Jun 2002 15:16:15 +0900, "Hideki Yamamoto" <hideki@hpc.bs1.fc.nec.co.jp> said:
> 
>   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
>