diff options
Diffstat (limited to 'extra/Configs/Config.in')
| -rw-r--r-- | extra/Configs/Config.in | 37 |
1 files changed, 0 insertions, 37 deletions
diff --git a/extra/Configs/Config.in b/extra/Configs/Config.in index b1624dafd..be80a3a7d 100644 --- a/extra/Configs/Config.in +++ b/extra/Configs/Config.in @@ -251,43 +251,6 @@ config UCLIBC_PROPOLICE gcc version, were __guard and __stack_smash_handler are removed from libgcc. Most people will answer N. -config UCLIBC_PROFILING - bool "Support gprof profiling" - default y - help - If you wish to build uClibc with support for application profiling - using the gprof tool, then you should enable this feature. Then in - addition to building uClibc with profiling support, you will also - need to recompile all your shared libraries with the profiling - enabled version of uClibc. To add profiling support to your - applications, you must compile things using the gcc options - "-fprofile-arcs -pg". Then when you run your applications, a - gmon.out file will be generated which can then be analyzed by - 'gprof'. - - These exist a number of less invasive alternatives that do not - require your to specially instrument your application, and recompile - and relink everything. - - Many people have had good results using the combination of Valgrind - to generate profiling information and KCachegrind for analysis: - http://developer.kde.org/~sewardj/ - http://kcachegrind.sourceforge.net/ - - The OProfile system-wide profiler is another alternative: - http://oprofile.sourceforge.net/ - - Prospect is another alternative based on OProfile: - http://prospect.sourceforge.net/ - - And the Linux Trace Toolkit (LTT) is also a fine tool: - http://www.opersys.com/LTT/ - - If none of these tools do what you need, you can of course enable - this option, rebuild everything, and use 'gprof'. There is both a - size and performance penalty to profiling your applications this way, - so most people should answer N. - config HAS_NO_THREADS bool default n |