Implementation.html 9.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189
  1. <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
  2. <html>
  3. <!-- This file documents the gprof profiler of the GNU system.
  4. Copyright (C) 1988-2017 Free Software Foundation, Inc.
  5. Permission is granted to copy, distribute and/or modify this document
  6. under the terms of the GNU Free Documentation License, Version 1.3
  7. or any later version published by the Free Software Foundation;
  8. with no Invariant Sections, with no Front-Cover Texts, and with no
  9. Back-Cover Texts. A copy of the license is included in the
  10. section entitled "GNU Free Documentation License".
  11. -->
  12. <!-- Created by GNU Texinfo 5.2, http://www.gnu.org/software/texinfo/ -->
  13. <head>
  14. <title>GNU gprof: Implementation</title>
  15. <meta name="description" content="GNU gprof: Implementation">
  16. <meta name="keywords" content="GNU gprof: Implementation">
  17. <meta name="resource-type" content="document">
  18. <meta name="distribution" content="global">
  19. <meta name="Generator" content="makeinfo">
  20. <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  21. <link href="index.html#Top" rel="start" title="Top">
  22. <link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
  23. <link href="Details.html#Details" rel="up" title="Details">
  24. <link href="File-Format.html#File-Format" rel="next" title="File Format">
  25. <link href="Details.html#Details" rel="prev" title="Details">
  26. <style type="text/css">
  27. <!--
  28. a.summary-letter {text-decoration: none}
  29. blockquote.smallquotation {font-size: smaller}
  30. div.display {margin-left: 3.2em}
  31. div.example {margin-left: 3.2em}
  32. div.indentedblock {margin-left: 3.2em}
  33. div.lisp {margin-left: 3.2em}
  34. div.smalldisplay {margin-left: 3.2em}
  35. div.smallexample {margin-left: 3.2em}
  36. div.smallindentedblock {margin-left: 3.2em; font-size: smaller}
  37. div.smalllisp {margin-left: 3.2em}
  38. kbd {font-style:oblique}
  39. pre.display {font-family: inherit}
  40. pre.format {font-family: inherit}
  41. pre.menu-comment {font-family: serif}
  42. pre.menu-preformatted {font-family: serif}
  43. pre.smalldisplay {font-family: inherit; font-size: smaller}
  44. pre.smallexample {font-size: smaller}
  45. pre.smallformat {font-family: inherit; font-size: smaller}
  46. pre.smalllisp {font-size: smaller}
  47. span.nocodebreak {white-space:nowrap}
  48. span.nolinebreak {white-space:nowrap}
  49. span.roman {font-family:serif; font-weight:normal}
  50. span.sansserif {font-family:sans-serif; font-weight:normal}
  51. ul.no-bullet {list-style: none}
  52. -->
  53. </style>
  54. </head>
  55. <body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
  56. <a name="Implementation"></a>
  57. <div class="header">
  58. <p>
  59. Next: <a href="File-Format.html#File-Format" accesskey="n" rel="next">File Format</a>, Up: <a href="Details.html#Details" accesskey="u" rel="up">Details</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p>
  60. </div>
  61. <hr>
  62. <a name="Implementation-of-Profiling"></a>
  63. <h3 class="section">9.1 Implementation of Profiling</h3>
  64. <p>Profiling works by changing how every function in your program is compiled
  65. so that when it is called, it will stash away some information about where
  66. it was called from. From this, the profiler can figure out what function
  67. called it, and can count how many times it was called. This change is made
  68. by the compiler when your program is compiled with the &lsquo;<samp>-pg</samp>&rsquo; option,
  69. which causes every function to call <code>mcount</code>
  70. (or <code>_mcount</code>, or <code>__mcount</code>, depending on the OS and compiler)
  71. as one of its first operations.
  72. </p>
  73. <p>The <code>mcount</code> routine, included in the profiling library,
  74. is responsible for recording in an in-memory call graph table
  75. both its parent routine (the child) and its parent&rsquo;s parent. This is
  76. typically done by examining the stack frame to find both
  77. the address of the child, and the return address in the original parent.
  78. Since this is a very machine-dependent operation, <code>mcount</code>
  79. itself is typically a short assembly-language stub routine
  80. that extracts the required
  81. information, and then calls <code>__mcount_internal</code>
  82. (a normal C function) with two arguments&mdash;<code>frompc</code> and <code>selfpc</code>.
  83. <code>__mcount_internal</code> is responsible for maintaining
  84. the in-memory call graph, which records <code>frompc</code>, <code>selfpc</code>,
  85. and the number of times each of these call arcs was traversed.
  86. </p>
  87. <p>GCC Version 2 provides a magical function (<code>__builtin_return_address</code>),
  88. which allows a generic <code>mcount</code> function to extract the
  89. required information from the stack frame. However, on some
  90. architectures, most notably the SPARC, using this builtin can be
  91. very computationally expensive, and an assembly language version
  92. of <code>mcount</code> is used for performance reasons.
  93. </p>
  94. <p>Number-of-calls information for library routines is collected by using a
  95. special version of the C library. The programs in it are the same as in
  96. the usual C library, but they were compiled with &lsquo;<samp>-pg</samp>&rsquo;. If you
  97. link your program with &lsquo;<samp>gcc &hellip; -pg</samp>&rsquo;, it automatically uses the
  98. profiling version of the library.
  99. </p>
  100. <p>Profiling also involves watching your program as it runs, and keeping a
  101. histogram of where the program counter happens to be every now and then.
  102. Typically the program counter is looked at around 100 times per second of
  103. run time, but the exact frequency may vary from system to system.
  104. </p>
  105. <p>This is done is one of two ways. Most UNIX-like operating systems
  106. provide a <code>profil()</code> system call, which registers a memory
  107. array with the kernel, along with a scale
  108. factor that determines how the program&rsquo;s address space maps
  109. into the array.
  110. Typical scaling values cause every 2 to 8 bytes of address space
  111. to map into a single array slot.
  112. On every tick of the system clock
  113. (assuming the profiled program is running), the value of the
  114. program counter is examined and the corresponding slot in
  115. the memory array is incremented. Since this is done in the kernel,
  116. which had to interrupt the process anyway to handle the clock
  117. interrupt, very little additional system overhead is required.
  118. </p>
  119. <p>However, some operating systems, most notably Linux 2.0 (and earlier),
  120. do not provide a <code>profil()</code> system call. On such a system,
  121. arrangements are made for the kernel to periodically deliver
  122. a signal to the process (typically via <code>setitimer()</code>),
  123. which then performs the same operation of examining the
  124. program counter and incrementing a slot in the memory array.
  125. Since this method requires a signal to be delivered to
  126. user space every time a sample is taken, it uses considerably
  127. more overhead than kernel-based profiling. Also, due to the
  128. added delay required to deliver the signal, this method is
  129. less accurate as well.
  130. </p>
  131. <p>A special startup routine allocates memory for the histogram and
  132. either calls <code>profil()</code> or sets up
  133. a clock signal handler.
  134. This routine (<code>monstartup</code>) can be invoked in several ways.
  135. On Linux systems, a special profiling startup file <code>gcrt0.o</code>,
  136. which invokes <code>monstartup</code> before <code>main</code>,
  137. is used instead of the default <code>crt0.o</code>.
  138. Use of this special startup file is one of the effects
  139. of using &lsquo;<samp>gcc &hellip; -pg</samp>&rsquo; to link.
  140. On SPARC systems, no special startup files are used.
  141. Rather, the <code>mcount</code> routine, when it is invoked for
  142. the first time (typically when <code>main</code> is called),
  143. calls <code>monstartup</code>.
  144. </p>
  145. <p>If the compiler&rsquo;s &lsquo;<samp>-a</samp>&rsquo; option was used, basic-block counting
  146. is also enabled. Each object file is then compiled with a static array
  147. of counts, initially zero.
  148. In the executable code, every time a new basic-block begins
  149. (i.e., when an <code>if</code> statement appears), an extra instruction
  150. is inserted to increment the corresponding count in the array.
  151. At compile time, a paired array was constructed that recorded
  152. the starting address of each basic-block. Taken together,
  153. the two arrays record the starting address of every basic-block,
  154. along with the number of times it was executed.
  155. </p>
  156. <p>The profiling library also includes a function (<code>mcleanup</code>) which is
  157. typically registered using <code>atexit()</code> to be called as the
  158. program exits, and is responsible for writing the file <samp>gmon.out</samp>.
  159. Profiling is turned off, various headers are output, and the histogram
  160. is written, followed by the call-graph arcs and the basic-block counts.
  161. </p>
  162. <p>The output from <code>gprof</code> gives no indication of parts of your program that
  163. are limited by I/O or swapping bandwidth. This is because samples of the
  164. program counter are taken at fixed intervals of the program&rsquo;s run time.
  165. Therefore, the
  166. time measurements in <code>gprof</code> output say nothing about time that your
  167. program was not running. For example, a part of the program that creates
  168. so much data that it cannot all fit in physical memory at once may run very
  169. slowly due to thrashing, but <code>gprof</code> will say it uses little time. On
  170. the other hand, sampling by run time has the advantage that the amount of
  171. load due to other users won&rsquo;t directly affect the output you get.
  172. </p>
  173. <hr>
  174. <div class="header">
  175. <p>
  176. Next: <a href="File-Format.html#File-Format" accesskey="n" rel="next">File Format</a>, Up: <a href="Details.html#Details" accesskey="u" rel="up">Details</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p>
  177. </div>
  178. </body>
  179. </html>