Re: gprof problem

• To: stoller@fast.cs.utah.edu, vlchung@cs.uwa.edu.au
• Subject: Re: gprof problem
• From: Mike Hibler <mike>
• Date: Thu, 19 Apr 2001 09:32:02 -0600 (MDT)
• Cc: oskit-users@fast.cs.utah.edu
• Sender: owner-oskit-users@fast.cs.utah.edu

I didn't notice the two libc thing that Leigh pointed out, but I linked it
with:

ld -Ttext 100000 -o test23 -L../../lib ../../lib/multiboot.o \
	gproftest.o -loskit_startup_p -loskit_memfs_p\
	-loskit_fsnamespace_r_p -loskit_kern_p\
	-loskit_threads_p -loskit_svm_p -loskit_amm_p\
	-loskit_com_p -loskit_bootp_p -loskit_freebsd_net_p\
	-loskit_linux_dev_p -loskit_clientos_p -loskit_dev_p\
	-loskit_kern_p -loskit_lmm_p -loskit_c_p -loskit_freebsd_c_p\
	-loskit_gprof_p -loskit_kern_p -loskit_c_p\
	-loskit_freebsd_c_r_p ../../lib/crtn.o

which differs from your link line in that I needed -loskit_svm
(and oskit_amm) because of the STACKGUARD code.  Anyway, this kernel worked,
it ran and spewed out the gprof output.  Note that, if you are using the
latest snapshot, you will need to replace -loskit_dev with -loskit_realtime
in order to get execution times.  We use a real-time clock interrupt for
collecting the execution profile (all other interrupts are virtualized)
allowing us to collect execution times for interrupt handlers.

• Prev: Re: gprof problem
• Next: Re: gprof problem
• Index(es):
  • Main
  • Thread