headers
jeff milam | 2 Jun 2003 12:57

gprof

Hello, my name is Jeffrey Milam.  I work at TecMasters.Inc in Lawton OK.    I 
was wondering if you could help me out with a problem i am having.  We are 
running a large simulation that links code from fortran and c.  The problem 
that i am having is that when producing the results, the flat profile has the 
number of times each function was called but it does not produce any 
times...such as percentage of time or total time for the functions.  Here is 
just the first couple of copied lines from the output file.

 %   cumulative   self              self     total
 time   seconds   seconds    calls  Ts/call  Ts/call  name
  0.00      0.00     0.00    44686     0.00     0.00  scrblk_
  0.00      0.00     0.00    14829     0.00     0.00  listv_
  0.00      0.00     0.00    11750     0.00     0.00  octal_
  0.00      0.00     0.00     8880     0.00     0.00  acsur_
  0.00      0.00     0.00     8880     0.00     0.00  idxdpl_
  0.00      0.00     0.00     7690     0.00     0.00  deplel_
  0.00      0.00     0.00     6828     0.00     0.00  deploy_
  0.00      0.00     0.00     4922     0.00     0.00  prtfu_
  0.00      0.00     0.00     3357     0.00     0.00  igrdid_
  0.00      0.00     0.00     3268     0.00     0.00  hashxy_

If you have any idea of what could be going wrong, could you help me...  I 
would greatly appreciate it.  Thank you

Jeff Milam
Permalink | Reply | 1 comment |
headers
Ben Elliston | 2 Jun 2003 23:39

Re: gprof

jeff milam <jmilam <at> tecmasters.com> writes:

> running a large simulation that links code from fortran and c.  The
> problem that i am having is that when producing the results, the
> flat profile has the number of times each function was called but it
> does not produce any times...such as percentage of time or total
> time for the functions.  Here is just the first couple of copied
> lines from the output file.

Are you compiling your program sources with -pg or -p?  You need to
use -pg.  You also need to make sure you analyse the gmon.out (not
mon.out) file using gprof(1) rather than prof(1).

Cheers, Ben
Permalink | Reply | 0 comments |
headers
matthew green | 3 Jun 2003 07:25
Picon
Favicon

re: CVS commit: src


   Modified Files:
   	src/lib/libc/stdlib: atoll.c
   	src/tools/compat: Makefile compat_defs.h configure configure.ac

   Log Message:
   Add atoll(3) to libnbcompat.  We need it when building target's gcc
   for a 64-bit target on a 32-bit host.

   NB: There seems to be a bug in either gcc itself or the way we import
   it, b/c the incorrect #define HAVE_ATOLL is picked from (e.g. for
   sparc64) gnu/usr.bin/gcc/arch/sparc64/auto-host.h - so when gen*
   auxilary (host) programs are built in gnu/usr.bin/gcc/backend, they
   incorrectly pick-up target's HAVE_ATOLL.

   For now providing atoll(3) in libnbcompat is a simple and sufficient
   workaround.

hmmm.. i guess this is because auto-host.h is generated on a netbsd
host... hmmmm not sure what the right solution here is - we need some
way of using the ones that configure would generate for the host,
which is probably the ones in src/tools/toolchain?  does this work
properly with EXTERNAL_TOOLCHAIN(?) - i'd guess not... what do we
do here?  have a small configure that is run to generate this?

.mrg.
Permalink | Reply | 0 comments |
headers
David Brownlee | 3 Jun 2003 16:32
Picon

Re: gcc3.3, perl, and '-O3 -march=k6-2' -> segfault

On Fri, 30 May 2003, Frederick Bruckman wrote:

> On Wed, 28 May 2003, Frederick Bruckman wrote:
>
> > On Wed, 28 May 2003, David wrote:
> >
> > > 	Tried to compile perl on an AMD K6-2 box here under gcc 3.3
> > > 	and the miniperl chokes with a segmentation fault. This is
> > > 	with '-O3 -march=k6-2'.
> > > 	Interesting the same flags work fine with gcc-3.2, and
> > > 	3.3 works fine with '-O3 -march=pentium3' on the next box.
> >
> > gcc 3.3 can't even build itself with ``gmake BOOT_CFLAGS="-O3 -march=k6-2"''
> > (AMD K6-2/533, model 8, stepping 12, underclocked at 500mHz). No such problem
> > with gcc-3.2.3.
>
> It take it all back. That was a pre-release 3.3. After updating to the
> "gcc_3_3_release" tag, "gcc" bootstrapped fine with "-O3 -march=k6-2
> -fomit-frame-pointer", and it built "mplayer" fine.

	The plot (or possibly the smoke) thickens: gcc-3.3 from outside
	pkgsrc builds perl-5.8 outside pkgsrc fine with '-O3 -march=k6-2'.
	Next to try a pkgsrc gcc-3.3 building a non pkgsrc perl-5.8...

--

-- 
		David/absolute          -- www.netbsd.org: No hype required --
Permalink | Reply | 3 comments |
headers
Matthias Drochner | 6 Jun 2003 17:01
Picon
Picon
Favicon

different behaviour of system cc and TOOLDIR/cc


Hi -
just found a strange (or at least for me ununderstandable)
difference in behaviour of the USE_TOOLS and the maintree compilers:

When building a shared lib with the main one everything looks well:

$ cc -v -shared -o mist.so xxx.o
Using builtin specs.
gcc version 2.95.3 20010315 (release) (NetBSD nb4)
 ld -m elf_i386 -shared -o mist.so /usr/lib/crti.o /usr/lib/crtbeginS.o
xxx.o -lgcc_pic -lgcc_pic /usr/lib/crtendS.o /usr/lib/crtn.o

The same with "tools" doesn't work:

$ /usr/tools/bin/i386--netbsdelf-gcc -v -shared -o mist.so xxx.o
Reading specs from /usr/tools/lib/gcc-lib/i386--netbsdelf/2.95.3/specs
gcc version 2.95.3 20010315 (release) (NetBSD nb4)
 /usr/tools/lib/gcc-lib/i386--netbsdelf/2.95.3/collect2 -m elf_i386 -sha
red -o mist.so crtbeginS.o -L/usr/tools/lib/gcc-lib/i386--netbsdelf/2.95
.3 -L/usr/tools/i386--netbsdelf/lib xxx.o crtendS.o
/usr/tools/i386--netbsdelf/bin/ld: cannot open crtbeginS.o: No such file
 or directory

Is this a bug or am I missing something?

best regards
Matthias
(Continue reading)

Permalink | Reply | 43 comments |
headers
Frederick Bruckman | 6 Jun 2003 18:09

Re: different behaviour of system cc and TOOLDIR/cc

On Fri, 6 Jun 2003, Matthias Drochner wrote:

> just found a strange (or at least for me ununderstandable)
> difference in behaviour of the USE_TOOLS and the maintree compilers:

"/usr/lib" isn't in the "libraries" search path for the toolchain
compiler. You can view the search paths with -print-search-dirs.

> Is this a bug or am I missing something?

I don't think so. Since the toolchain compiler is (potentially) a
cross compiler, you really don't want it searching in the base system.
Note that for the NetBSD build, all the "${DESTDIR}/lib/crt*" files
are supplied on the command line.

Frederick
Permalink | Reply | 0 comments |
headers
Jason Thorpe | 6 Jun 2003 19:18

Re: different behaviour of system cc and TOOLDIR/cc


On Friday, June 6, 2003, at 08:01  AM, Matthias Drochner wrote:

> Hi -
> just found a strange (or at least for me ununderstandable)
> difference in behaviour of the USE_TOOLS and the maintree compilers:
>
> When building a shared lib with the main one everything looks well:
>
> $ cc -v -shared -o mist.so xxx.o
> Using builtin specs.
> gcc version 2.95.3 20010315 (release) (NetBSD nb4)
>  ld -m elf_i386 -shared -o mist.so /usr/lib/crti.o /usr/lib/crtbeginS.o
> xxx.o -lgcc_pic -lgcc_pic /usr/lib/crtendS.o /usr/lib/crtn.o
>
> The same with "tools" doesn't work:
>
> $ /usr/tools/bin/i386--netbsdelf-gcc -v -shared -o mist.so xxx.o
> Reading specs from /usr/tools/lib/gcc-lib/i386--netbsdelf/2.95.3/specs
> gcc version 2.95.3 20010315 (release) (NetBSD nb4)
>  /usr/tools/lib/gcc-lib/i386--netbsdelf/2.95.3/collect2 -m elf_i386 
> -sha
> red -o mist.so crtbeginS.o 
> -L/usr/tools/lib/gcc-lib/i386--netbsdelf/2.95
> .3 -L/usr/tools/i386--netbsdelf/lib xxx.o crtendS.o
> /usr/tools/i386--netbsdelf/bin/ld: cannot open crtbeginS.o: No such 
> file
>  or directory
>
> Is this a bug or am I missing something?
(Continue reading)

Permalink | Reply | 7 comments |
headers
Matthias Drochner | 6 Jun 2003 22:48
Picon
Picon
Favicon

Re: different behaviour of system cc and TOOLDIR/cc


fredb <at> immanent.net said:
> Since the toolchain compiler is (potentially) a cross compiler, you
> really don't want it searching in the base system.

Hmm - isn't this what the -nostdlib flag is for?

It shouldn't use anything of the base system unless directed
by -L or so, agreed. However these crt* files have a strange
status somehow - they don't belong to the target system, otherwise
they should be found by -L${DESTDIR}, but they also are not
part of the toolchain, otherwise they should reside in ${TOOLDOR}/...

thorpej <at> wasabisystems.com said:
> Whenever you use the TOOLDIR gcc, you basically need to do the
> -nostdlib dance and specifiy the libraries/crt files manually, just as
>  <bsd.*.mk> do. 

OK, but this is somehow unsatisfying because information
is duplicated: The *.mk files have to know which crt* files
are to be linked in, in addition to the compiler's specs.

What I'm trying to get solved is that shared libraries are
not linked against libgcc_pic.a if <bsd.lib.mk> is used.
Just using ${CC} instead of ${LD} to build the lib works,
but only as long as USETOOLS==no.
Would be easily solved by wiring -lgcc_pic into bsd.lib.mk,
but I'd consider this ugly for the readons mentioned.
And there might be issues wrt a gcc-3 migration...
(Continue reading)

Permalink | Reply | 6 comments |
headers
Frederick Bruckman | 7 Jun 2003 03:59

Re: different behaviour of system cc and TOOLDIR/cc

On Fri, 6 Jun 2003, Matthias Drochner wrote:

> fredb <at> immanent.net said:
> > Since the toolchain compiler is (potentially) a cross compiler, you
> > really don't want it searching in the base system.
>
> Hmm - isn't this what the -nostdlib flag is for?

A cross compiler should link targets with the host objects
approximately never, so unless you hardcode ${DESTDIR} into the
compiler, it might as well break without the correct options for
native builds, too, to help catch mistakes (or so I hear).

> It shouldn't use anything of the base system unless directed
> by -L or so, agreed. However these crt* files have a strange
> status somehow - they don't belong to the target system, otherwise
> they should be found by -L${DESTDIR}, but they also are not
> part of the toolchain, otherwise they should reside in ${TOOLDOR}/...

They're not even libraries. I guess that's why "-L" doesn't work.
"-B${DESTDIR}/usr/lib/" seems to do it, though.

> thorpej <at> wasabisystems.com said:
> > Whenever you use the TOOLDIR gcc, you basically need to do the
> > -nostdlib dance and specifiy the libraries/crt files manually, just as
> >  <bsd.*.mk> do.
>
> OK, but this is somehow unsatisfying because information
> is duplicated: The *.mk files have to know which crt* files
> are to be linked in, in addition to the compiler's specs.
(Continue reading)

Permalink | Reply | 4 comments |
headers
matthew green | 7 Jun 2003 08:31
Picon
Favicon

re: different behaviour of system cc and TOOLDIR/cc


   fredb <at> immanent.net said:
   > Since the toolchain compiler is (potentially) a cross compiler, you
   > really don't want it searching in the base system.

i think it's truer to say that the compiler built by src/tools/toolchain
is *always* a cross compiler, even if targetted for the same machine as
the build.  if you look, you'll see that -DCROSS_COMPILER is defined...

that is the reason why it doesn't look in /usr/lib (etc)

.mrg.
Permalink | Reply | 0 comments |

Gmane