Profiling on mips-irix6? (Testcase gcc.dg/nest.c failure)

Jim Wilson wilson@redhat.com
Thu Oct 3 11:35:00 GMT 2002


Historically, SGI mips based systems have never supported gprof based
profiling.  This is because they have pixie/pixstats which is a more flexible
tool, and thus they apparently felt that they didn't need gprof.  Later pixie
was replaced by tools with fancy names, e.g. speedshop, but I think it is
still basically pixie underneath the covers.

The gcrt1.o stuff is in there on the principle that eventually someone would
port gprof to mips-sgi-irix systems, and hence we would need it anyways even
though the OS doesn't support gprof.

libprof1.a is for prof not gprof.  I think prof and its libraries are supposed
to be there.  It is only gprof/gcrt1.o that is missing from the OS.

gprof requires both compiler and library support in order to work.  I
think it makes sense to supply the compiler part even if the library part
is missing, because that makes it easier for library people to supply their
missing part, and gives them some incentive to do so.

If someone has reported that gprof profiling doesn't work on an irix system,
then the correct answer is to tell them that the OS doesn't support gprof.
I suppose we could change the irix ports to give an error message or ignore
the option instead of complaining about missing files.  I don't really care
anymore how this specific issue is handled.

Testcases that use -pg aren't portable, since not every OS supports gprof.
gprof was a BSD invention, and lots of AT&T derived OSes never supported it.
Plus on anything that isn't unix, you can't expect -pg to work.  This can
work only if gcc silently ignores -pg on all systems where gprof doesn't
work, but it is rude for gcc to silently ignore an option when it doesn't
work.  Getting an error from the irix compiler for -pg is somewhat better
than just ignoring it, though one could argue it either way.

Jim



More information about the Gcc-bugs mailing list