public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "kris dot demuynck at esat dot kuleuven dot ac dot be" <sourceware-bugzilla@sources.redhat.com>
To: glibc-bugs@sources.redhat.com
Subject: [Bug libc/372] New: gprof, ITIMER_PROF
Date: Wed, 08 Sep 2004 13:15:00 -0000	[thread overview]
Message-ID: <20040908131525.372.kris.demuynck@esat.kuleuven.ac.be> (raw)

With my current installation of linux/gcc/libc (specifications, see below),
gprof does no longer function correctly.
In the best case, gprof reports the actual timings x10. The reason seems to be
that the ITIMER_PROF interval timer is set to 999usec instead of 9999usec.
Note: Since the system clock/timer also went from 100Hz to 1000Hz, these two
timers may be correlated.

The main problem is not the factor 10 (my math is still that good), but the
overflow of the 16 bit counters gprof uses to derive it statistics. If a
program contains a single hot-spot, the counter may overflow from the moment
the program takes longer than 65536*1msec = 1min 5sec. This renders gprof
useless for all but the simplest programs.

Changing the precision of the counters may be difficult; see quote below from
Jim Wilson (I first sent a bug-report to gcc since I assumed the ITIMER_PROF was
set in gcrt1.o, but gcrt1.o only calls __monstartup() in glibc).
> This stems from a limitation of the profil() system call, which requires an
> unsigned short * parameter.  Thus fixing this means a kernel change (and
> perhaps a new system call to avoid breaking standards conformance), a glibc
> change, and a binutils change.  No gcc changes should be needed.  This will
> probably be difficult to coordinate and accomplish.

The easiest solution probably is to set the ITIMER_PROF to 9999 usec,
irrespective of the system clock (this provided reasonable results in my tests).

Details of the system used:
  gcc:    3.4.1
  kernel: 2.6.7-1.494.2.2smp
  libc:   GNU C Library stable release version 2.3.3
  gprof:  GNU gprof 2.15.90.0.3

-- 
           Summary: gprof, ITIMER_PROF
           Product: glibc
           Version: 2.3.3
            Status: NEW
          Severity: minor
          Priority: P3
         Component: libc
        AssignedTo: gotom at debian dot or dot jp
        ReportedBy: kris dot demuynck at esat dot kuleuven dot ac dot be
                CC: glibc-bugs at sources dot redhat dot com


http://sources.redhat.com/bugzilla/show_bug.cgi?id=372

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


             reply	other threads:[~2004-09-08 13:15 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-08 13:15 kris dot demuynck at esat dot kuleuven dot ac dot be [this message]
2005-09-22 18:44 ` [Bug libc/372] " drepper at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040908131525.372.kris.demuynck@esat.kuleuven.ac.be \
    --to=sourceware-bugzilla@sources.redhat.com \
    --cc=glibc-bugs@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).