Re: gprof output

[gprof output bug]
> > even more I get different result from one run to another of oprofpp
> > on the same samples files.
Sorry it was a silly bug in my test procedure.
I am commiting a patch for an another corner case bug
in gprof output
regards
phil

On Wed, Sep 19, 2001 at 08:20:38PM -0700, Philippe Elie wrote:
> - $(CC) $(CFLAGS) $(INCLUDES) -o $@ $(SOURCES) $(LIBS)
> + g++ $(CFLAGS) $(INCLUDES) -o $@ $(SOURCES) $(LIBS)
This should be $(CXX) $(CXXFLAGS) everywhere
I'll look at the actual code now and test gprof.
regards
john
p.s. I have created BRANCH_NO_THREAD for compiling without the kernel thread.
Check it out (pun intended) - not sure what to do about the userspace issue mentioned.

> > - $(CC) $(CFLAGS) $(INCLUDES) -o $@ $(SOURCES) $(LIBS)
> > + g++ $(CFLAGS) $(INCLUDES) -o $@ $(SOURCES) $(LIBS)
>
> This should be $(CXX) $(CXXFLAGS) everywhere
Is our Makefile needs auto deps and build things in a separate objs dir ?
There is a tricky example to do this in the doc of make (I have used it
and it work very well) but this require the use of an extension of gnu make
>
> I'll look at the actual code now and test gprof.
ok: old results of gprof output shows for a samples files with 251 samples
100.02% 251 251
and now it show
100.2% 145678 145678
even more I get different result from one run to another of oprofpp
on the same samples files.
***
are you working on the gui ?
regards
phil

On Thu, Sep 20, 2001 at 08:19:22PM +0200, Philippe Elie wrote:
> > > - $(CC) $(CFLAGS) $(INCLUDES) -o $@ $(SOURCES) $(LIBS)
> > > + g++ $(CFLAGS) $(INCLUDES) -o $@ $(SOURCES) $(LIBS)
> >
> > This should be $(CXX) $(CXXFLAGS) everywhere
>
> Is our Makefile needs auto deps and build things in a separate objs dir ?
> There is a tricky example to do this in the doc of make (I have used it
> and it work very well) but this require the use of an extension of gnu make
gnu make extensions are OK, if you want to do this. Certainly the makefiles suck.
> ok: old results of gprof output shows for a samples files with 251 samples
>
> 100.02% 251 251
>
> and now it show
>
> 100.2% 145678 145678
>
> even more I get different result from one run to another of oprofpp
> on the same samples files.
humph, I have to look later because I still have compile issues with the popt call
in oprofpp.c
> are you working on the gui ?
yes, bit by bit.
I've been running tests on the no-thread stuff. Unfortunately the results are dissapointing
and confusing :
686.93 (0.00%) | 40.25 (0.00%) | 365.33 (0.00%) | clean1.out
687.01 (0.01%) | 40.38 (0.32%) | 366.81 (0.40%) | clean2.out
686.70 (-0.03%) | 40.51 (0.65%) | 366.42 (0.30%) | clean3.out
687.52 (0.09%) | 40.11 (-0.34%) | 366.78 (0.40%) | clean4.out
687.12 (0.03%) | 40.11 (-0.34%) | 366.18 (0.23%) | clean5.out
690.55 (0.53%) | 40.58 (0.82%) | 367.67 (0.64%) | t-400000.out
690.07 (0.46%) | 40.71 (1.14%) | 368.74 (0.93%) | nt-400000.out
726.85 (5.81%) | 43.20 (7.33%) | 390.06 (6.77%) | t-25000.out
725.03 (5.55%) | 44.08 (9.51%) | 389.45 (6.60%) | nt-25000.out
cpu_clk_unhalted, t == with oprof_thread, nt == w/o oprof_thread
Longer runs gave similar results.
I don't know what to make of this at all. It looks like there is no point in
removing the thread (Also we have problems with non-user-space-profiling runs).
regards
john
--
"If you're not part of the problem, you're part of the problem space."

[gprof output bug]
> > even more I get different result from one run to another of oprofpp
> > on the same samples files.
Sorry it was a silly bug in my test procedure.
I am commiting a patch for an another corner case bug
in gprof output
regards
phil