summaryrefslogtreecommitdiff
path: root/libstdc++-v3/doc/html/manual/bk01pt03ch19s05.html
diff options
context:
space:
mode:
authorupstream source tree <ports@midipix.org>2015-03-15 20:14:05 -0400
committerupstream source tree <ports@midipix.org>2015-03-15 20:14:05 -0400
commit554fd8c5195424bdbcabf5de30fdc183aba391bd (patch)
tree976dc5ab7fddf506dadce60ae936f43f58787092 /libstdc++-v3/doc/html/manual/bk01pt03ch19s05.html
downloadcbb-gcc-4.6.4-554fd8c5195424bdbcabf5de30fdc183aba391bd.tar.bz2
cbb-gcc-4.6.4-554fd8c5195424bdbcabf5de30fdc183aba391bd.tar.xz
obtained gcc-4.6.4.tar.bz2 from upstream website;upstream
verified gcc-4.6.4.tar.bz2.sig; imported gcc-4.6.4 source tree from verified upstream tarball. downloading a git-generated archive based on the 'upstream' tag should provide you with a source tree that is binary identical to the one extracted from the above tarball. if you have obtained the source via the command 'git clone', however, do note that line-endings of files in your working directory might differ from line-endings of the respective files in the upstream repository.
Diffstat (limited to 'libstdc++-v3/doc/html/manual/bk01pt03ch19s05.html')
-rw-r--r--libstdc++-v3/doc/html/manual/bk01pt03ch19s05.html51
1 files changed, 51 insertions, 0 deletions
diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch19s05.html b/libstdc++-v3/doc/html/manual/bk01pt03ch19s05.html
new file mode 100644
index 000000000..2d072f0b4
--- /dev/null
+++ b/libstdc++-v3/doc/html/manual/bk01pt03ch19s05.html
@@ -0,0 +1,51 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml"><head><title>Implementation Issues</title><meta name="generator" content="DocBook XSL-NS Stylesheets V1.76.1"/><meta name="keywords" content="&#10; C++&#10; , &#10; library&#10; , &#10; profile&#10; "/><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; "/><link rel="home" href="../spine.html" title="The GNU C++ Library"/><link rel="up" href="profile_mode.html" title="Chapter 19. Profile Mode"/><link rel="prev" href="bk01pt03ch19s04.html" title="Empirical Cost Model"/><link rel="next" href="bk01pt03ch19s06.html" title="Developer Information"/></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Implementation Issues</th></tr><tr><td align="left"><a accesskey="p" href="bk01pt03ch19s04.html">Prev</a> </td><th width="60%" align="center">Chapter 19. Profile Mode</th><td align="right"> <a accesskey="n" href="bk01pt03ch19s06.html">Next</a></td></tr></table><hr/></div><div class="section" title="Implementation Issues"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.profile_mode.implementation"/>Implementation Issues</h2></div></div></div><div class="section" title="Stack Traces"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.implementation.stack"/>Stack Traces</h3></div></div></div><p>
+ Accurate stack traces are needed during profiling since we group events by
+ call context and dynamic instance. Without accurate traces, diagnostics
+ may be hard to interpret. For instance, when giving advice to the user
+ it is imperative to reference application code, not library code.
+ </p><p>
+ Currently we are using the libc <code class="code">backtrace</code> routine to get
+ stack traces.
+ <code class="code">_GLIBCXX_PROFILE_STACK_DEPTH</code> can be set
+ to 0 if you are willing to give up call context information, or to a small
+ positive value to reduce run time overhead.
+ </p></div><div class="section" title="Symbolization of Instruction Addresses"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.implementation.symbols"/>Symbolization of Instruction Addresses</h3></div></div></div><p>
+ The profiling and analysis phases use only instruction addresses.
+ An external utility such as addr2line is needed to postprocess the result.
+ We do not plan to add symbolization support in the profile extension.
+ This would require access to symbol tables, debug information tables,
+ external programs or libraries and other system dependent information.
+ </p></div><div class="section" title="Concurrency"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.implementation.concurrency"/>Concurrency</h3></div></div></div><p>
+ Our current model is simplistic, but precise.
+ We cannot afford to approximate because some of our diagnostics require
+ precise matching of operations to container instance and call context.
+ During profiling, we keep a single information table per diagnostic.
+ There is a single lock per information table.
+ </p></div><div class="section" title="Using the Standard Library in the Instrumentation Implementation"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.implementation.stdlib-in-proflib"/>Using the Standard Library in the Instrumentation Implementation</h3></div></div></div><p>
+ As much as we would like to avoid uses of libstdc++ within our
+ instrumentation library, containers such as unordered_map are very
+ appealing. We plan to use them as long as they are named properly
+ to avoid ambiguity.
+ </p></div><div class="section" title="Malloc Hooks"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.implementation.malloc-hooks"/>Malloc Hooks</h3></div></div></div><p>
+ User applications/libraries can provide malloc hooks.
+ When the implementation of the malloc hooks uses stdlibc++, there can
+ be an infinite cycle between the profile mode instrumentation and the
+ malloc hook code.
+ </p><p>
+ We protect against reentrance to the profile mode instrumentation code,
+ which should avoid this problem in most cases.
+ The protection mechanism is thread safe and exception safe.
+ This mechanism does not prevent reentrance to the malloc hook itself,
+ which could still result in deadlock, if, for instance, the malloc hook
+ uses non-recursive locks.
+ XXX: A definitive solution to this problem would be for the profile extension
+ to use a custom allocator internally, and perhaps not to use libstdc++.
+ </p></div><div class="section" title="Construction and Destruction of Global Objects"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.implementation.construction-destruction"/>Construction and Destruction of Global Objects</h3></div></div></div><p>
+ The profiling library state is initialized at the first call to a profiling
+ method. This allows us to record the construction of all global objects.
+ However, we cannot do the same at destruction time. The trace is written
+ by a function registered by <code class="code">atexit</code>, thus invoked by
+ <code class="code">exit</code>.
+ </p></div></div><div class="navfooter"><hr/><table width="100%" summary="Navigation footer"><tr><td align="left"><a accesskey="p" href="bk01pt03ch19s04.html">Prev</a> </td><td align="center"><a accesskey="u" href="profile_mode.html">Up</a></td><td align="right"> <a accesskey="n" href="bk01pt03ch19s06.html">Next</a></td></tr><tr><td align="left" valign="top">Empirical Cost Model </td><td align="center"><a accesskey="h" href="../spine.html">Home</a></td><td align="right" valign="top"> Developer Information</td></tr></table></div></body></html>