Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
2001 |
Jan
(1) |
Feb
|
Mar
(7) |
Apr
(3) |
May
(3) |
Jun
(7) |
Jul
(10) |
Aug
(1) |
Sep
(50) |
Oct
(74) |
Nov
(28) |
Dec
(32) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(63) |
Feb
(27) |
Mar
(88) |
Apr
(21) |
May
(59) |
Jun
(41) |
Jul
(61) |
Aug
(89) |
Sep
(179) |
Oct
(152) |
Nov
(190) |
Dec
(92) |
2003 |
Jan
(140) |
Feb
(160) |
Mar
(193) |
Apr
(107) |
May
(84) |
Jun
(60) |
Jul
(97) |
Aug
(97) |
Sep
(42) |
Oct
(105) |
Nov
(99) |
Dec
(52) |
2004 |
Jan
(99) |
Feb
(97) |
Mar
(62) |
Apr
(73) |
May
(94) |
Jun
(37) |
Jul
(32) |
Aug
(89) |
Sep
(87) |
Oct
(72) |
Nov
(114) |
Dec
(35) |
2005 |
Jan
(25) |
Feb
(42) |
Mar
(120) |
Apr
(151) |
May
(71) |
Jun
(36) |
Jul
(35) |
Aug
(92) |
Sep
(19) |
Oct
(57) |
Nov
(77) |
Dec
(61) |
2006 |
Jan
(107) |
Feb
(114) |
Mar
(66) |
Apr
(101) |
May
(74) |
Jun
(64) |
Jul
(42) |
Aug
(51) |
Sep
(106) |
Oct
(118) |
Nov
(138) |
Dec
(162) |
2007 |
Jan
(148) |
Feb
(222) |
Mar
(73) |
Apr
(160) |
May
(166) |
Jun
(125) |
Jul
(184) |
Aug
(58) |
Sep
(41) |
Oct
(102) |
Nov
(111) |
Dec
(52) |
2008 |
Jan
(104) |
Feb
(67) |
Mar
(48) |
Apr
(125) |
May
(114) |
Jun
(98) |
Jul
(206) |
Aug
(89) |
Sep
(88) |
Oct
(163) |
Nov
(115) |
Dec
(113) |
2009 |
Jan
(131) |
Feb
(85) |
Mar
(157) |
Apr
(198) |
May
(202) |
Jun
(154) |
Jul
(156) |
Aug
(75) |
Sep
(80) |
Oct
(148) |
Nov
(88) |
Dec
(83) |
2010 |
Jan
(78) |
Feb
(59) |
Mar
(89) |
Apr
(54) |
May
(92) |
Jun
(66) |
Jul
(38) |
Aug
(73) |
Sep
(84) |
Oct
(91) |
Nov
(52) |
Dec
(62) |
2011 |
Jan
(86) |
Feb
(68) |
Mar
(129) |
Apr
(121) |
May
(154) |
Jun
(81) |
Jul
(55) |
Aug
(55) |
Sep
(58) |
Oct
(115) |
Nov
(88) |
Dec
(95) |
2012 |
Jan
(105) |
Feb
(62) |
Mar
(52) |
Apr
(54) |
May
(103) |
Jun
(89) |
Jul
(152) |
Aug
(73) |
Sep
(58) |
Oct
(60) |
Nov
(52) |
Dec
(90) |
2013 |
Jan
(102) |
Feb
(63) |
Mar
(68) |
Apr
(128) |
May
(82) |
Jun
(94) |
Jul
(87) |
Aug
(29) |
Sep
(24) |
Oct
(25) |
Nov
(40) |
Dec
(51) |
2014 |
Jan
(41) |
Feb
(60) |
Mar
(33) |
Apr
(22) |
May
(38) |
Jun
(23) |
Jul
(86) |
Aug
(113) |
Sep
(23) |
Oct
(22) |
Nov
(18) |
Dec
(13) |
2015 |
Jan
(40) |
Feb
(12) |
Mar
(28) |
Apr
(32) |
May
(53) |
Jun
(65) |
Jul
(27) |
Aug
(6) |
Sep
(13) |
Oct
(25) |
Nov
(48) |
Dec
(19) |
2016 |
Jan
(5) |
Feb
(10) |
Mar
(23) |
Apr
(31) |
May
(19) |
Jun
(28) |
Jul
(19) |
Aug
(2) |
Sep
(9) |
Oct
(18) |
Nov
(10) |
Dec
(4) |
2017 |
Jan
(23) |
Feb
(42) |
Mar
(13) |
Apr
(5) |
May
(7) |
Jun
(26) |
Jul
(13) |
Aug
(8) |
Sep
(1) |
Oct
(3) |
Nov
(27) |
Dec
(4) |
2018 |
Jan
(9) |
Feb
(22) |
Mar
(27) |
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
|
|
1
|
2
(1) |
3
|
4
|
5
(2) |
6
(2) |
7
(5) |
8
(3) |
9
|
10
|
11
|
12
(7) |
13
|
14
(5) |
15
(2) |
16
(7) |
17
(1) |
18
|
19
(1) |
20
(7) |
21
(6) |
22
(2) |
23
(1) |
24
(1) |
25
|
26
(2) |
27
|
28
|
29
(1) |
30
(5) |
31
|
From: Nicolas Savoire <nicos@ma...> - 2005-12-30 12:34:51
|
this patch fixed my problem ! My gcc version is 3.4.5, oprofile is 0.9.1, libbfd is 2.16.1. Thanks, nicolas On Friday 30 December 2005 13:01, Philippe Elie wrote: > On Fri, 30 Dec 2005 at 12:51 +0000, Philippe Elie wrote: > > oops > > > RCS file: /cvsroot/oprofile/oprofile/libutil++/bfd_support.cpp,v > > retrieving revision 1.2 > > diff -u -p -r1.2 bfd_support.cpp > > --- libutil++/bfd_support.cpp 2 Jun 2005 20:24:46 -0000 1.2 > > +++ libutil++/bfd_support.cpp 30 Dec 2005 11:43:31 -0000 > > @@ -531,7 +531,7 @@ find_nearest_line(bfd_info const & b, op > > ret = bfd_find_nearest_line(abfd, section, syms, pc, &cfilename, > > &function, &linenr); > > > > - if (!ret || !cfilename) > > + if (!ret || !cfilename && !function) > > ^^ oops > > > goto fail; > > > > if (!is_correct_function(function, sym.name())) > > try this one rather :) > > regards, > Philippe Elie > |
From: Philippe Elie <phil.el@wa...> - 2005-12-30 11:57:50
|
On Fri, 30 Dec 2005 at 12:51 +0000, Philippe Elie wrote: oops > RCS file: /cvsroot/oprofile/oprofile/libutil++/bfd_support.cpp,v > retrieving revision 1.2 > diff -u -p -r1.2 bfd_support.cpp > --- libutil++/bfd_support.cpp 2 Jun 2005 20:24:46 -0000 1.2 > +++ libutil++/bfd_support.cpp 30 Dec 2005 11:43:31 -0000 > @@ -531,7 +531,7 @@ find_nearest_line(bfd_info const & b, op > ret = bfd_find_nearest_line(abfd, section, syms, pc, &cfilename, > &function, &linenr); > > - if (!ret || !cfilename) > + if (!ret || !cfilename && !function) ^^ oops > goto fail; > > if (!is_correct_function(function, sym.name())) > try this one rather :) regards, Philippe Elie Index: libutil++/bfd_support.cpp =================================================================== RCS file: /cvsroot/oprofile/oprofile/libutil++/bfd_support.cpp,v retrieving revision 1.2 diff -u -p -r1.2 bfd_support.cpp --- libutil++/bfd_support.cpp 2 Jun 2005 20:24:46 -0000 1.2 +++ libutil++/bfd_support.cpp 30 Dec 2005 11:54:59 -0000 @@ -531,7 +531,7 @@ find_nearest_line(bfd_info const & b, op ret = bfd_find_nearest_line(abfd, section, syms, pc, &cfilename, &function, &linenr); - if (!ret || !cfilename) + if (!ret || !cfilename || !function) goto fail; if (!is_correct_function(function, sym.name())) |
From: Philippe Elie <phil.el@wa...> - 2005-12-30 11:47:49
|
On Fri, 30 Dec 2005 at 12:21 +0000, nicos@... wrote: > opreport -lg fails with basic_string::_S_construct NULL not valid > > An exception seems to be thrown by libstdc++ > call stack when exception is thrown: > #0 0xb7ece6eb in __cxa_throw () > from /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.so.6 > #1 0xb7e6f953 in std::__throw_logic_error () > from /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.so.6 > #2 0xb7eb0c14 in std::basic_string<char, std::char_traits<char>, > std::allocator<char> >::basic_string () > from /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.so.6 > #3 0xb7eb0cd6 in std::basic_string<char, std::char_traits<char>, > std::allocator<char> >::basic_string () > from /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.so.6 > #4 0x080ae019 in find_nearest_line (b=@0xbffd3d60, sym=@0xa841a20, > offset=16096) at bfd_support.cpp:537 > #5 0x080a915d in op_bfd::get_linenr (this=0xbffd3d40, sym_idx=1, > offset=16096, source_filename=@0xbffd3c10, linenr=@0xbffd3c4c) at > op_bfd.cpp:338 > #6 0x08088dbe in profile_container::add (this=0xbffd3e50, > profile=@0xbffd3cd0, abfd=@0xbffd3d40, app_name=@0x8112bf8, pclass=0) > at profile_container.cpp:101 > #7 0x08087026 in populate_for_image (archive_path=@0x80e51d0, > samples=@0xbffd3e50, ip=@0x8121840, symbol_filter=@0x80e51e0, > has_debug_info=0x0) > at populate.cpp:85 > #8 0x0804e4b5 in (anonymous namespace)::opreport (spec=@0xbffd3f10) at > opreport.cpp:529 > #9 0x08060c05 in run_pp_tool (argc=2, argv=0xbffd3ff4, fct=0x804df46 > <(anonymous namespace)::opreport(options::spec const&)>) > at common_option.cpp:193 > #10 0x0804e598 in main (argc=2, argv=0xbffd3ff4) at opreport.cpp:544 > > Thanks in advance for your help ! Not the first time we get something related to this bug but the first stack trace we get, helpfull! Can you provide your libbfd, gcc and oprofile version. Try this patch too: regards, Philippe Elie Index: libutil++/bfd_support.cpp =================================================================== RCS file: /cvsroot/oprofile/oprofile/libutil++/bfd_support.cpp,v retrieving revision 1.2 diff -u -p -r1.2 bfd_support.cpp --- libutil++/bfd_support.cpp 2 Jun 2005 20:24:46 -0000 1.2 +++ libutil++/bfd_support.cpp 30 Dec 2005 11:43:31 -0000 @@ -531,7 +531,7 @@ find_nearest_line(bfd_info const & b, op ret = bfd_find_nearest_line(abfd, section, syms, pc, &cfilename, &function, &linenr); - if (!ret || !cfilename) + if (!ret || !cfilename && !function) goto fail; if (!is_correct_function(function, sym.name())) |
From: <nicos@ma...> - 2005-12-30 11:21:38
|
opreport -lg fails with basic_string::_S_construct NULL not valid An exception seems to be thrown by libstdc++ call stack when exception is thrown: #0 0xb7ece6eb in __cxa_throw () from /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.so.6 #1 0xb7e6f953 in std::__throw_logic_error () from /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.so.6 #2 0xb7eb0c14 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string () from /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.so.6 #3 0xb7eb0cd6 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string () from /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.so.6 #4 0x080ae019 in find_nearest_line (b=@0xbffd3d60, sym=@0xa841a20, offset=16096) at bfd_support.cpp:537 #5 0x080a915d in op_bfd::get_linenr (this=0xbffd3d40, sym_idx=1, offset=16096, source_filename=@0xbffd3c10, linenr=@0xbffd3c4c) at op_bfd.cpp:338 #6 0x08088dbe in profile_container::add (this=0xbffd3e50, profile=@0xbffd3cd0, abfd=@0xbffd3d40, app_name=@0x8112bf8, pclass=0) at profile_container.cpp:101 #7 0x08087026 in populate_for_image (archive_path=@0x80e51d0, samples=@0xbffd3e50, ip=@0x8121840, symbol_filter=@0x80e51e0, has_debug_info=0x0) at populate.cpp:85 #8 0x0804e4b5 in (anonymous namespace)::opreport (spec=@0xbffd3f10) at opreport.cpp:529 #9 0x08060c05 in run_pp_tool (argc=2, argv=0xbffd3ff4, fct=0x804df46 <(anonymous namespace)::opreport(options::spec const&)>) at common_option.cpp:193 #10 0x0804e598 in main (argc=2, argv=0xbffd3ff4) at opreport.cpp:544 Thanks in advance for your help ! |
From: Al Stone <ahs3@fc...> - 2005-12-30 00:56:19
|
As reported in Debian bug #344665 [1], there's a minor typo in the opcontrol man page. Attached is a small patch I created to correct it. Thanks to Mike Carlson <corfe83dev at gmail dot com> for pointing out the problem. Grammar and/or spell-checking welcomed :). Index: oprofile-patched/doc/opcontrol.1.in =================================================================== RCS file: /cvsroot/oprofile/oprofile/doc/opcontrol.1.in,v retrieving revision 1.18 diff -r1.18 opcontrol.1.in 51c51 < of information saved in ~root/.oprofile/daemonrc. --- > or with information saved in ~root/.oprofile/daemonrc. References: [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=344665 -- Ciao, al ---------------------------------------------------------------------- Al Stone Alter Ego: Open Source and Linux R&D Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: ahs3@... ahs3@... ---------------------------------------------------------------------- |
From: William Cohen <wcohen@nc...> - 2005-12-26 15:43:41
|
Puneet Goel wrote: > HI, > > I am getting some problem while compiling my Redhat 9 kernel 2.4.20 > > #cd /usr/src/linux > #make menuconfig > > I enabled OProfile in the profiling menu and set |CONFIG_PROFILING=y| > and |CONFIG_OPROFILE=y| in the .config file. Also enabled Local APIC and > IO-APIC in the "Processor type and features" menu. > > #make dep > #make bzImage Hi, I am guessing that you are recompiling a uniprocessor kernel to have OProfile support. On most machines you can safely install an SMP kernel and use that to get the OProfile support. That avoids the hassles of building and installing your own kernel. I am not sure specifically why you are getting the error messages. You might save your .config file outside of the kernel source directory and do a "make mrproper" to make sure that everything is really cleaned. Then copy the .config file back into the directory. You might also use "CONFIG_OPROFILE=m" in the configuration rather than compiling the driver into the kernel. -Will > > Now i am getting errors: > > > arch/i386/oprofile/oprofile.o(.text+0x1470): In function `dcache_dir_close': > : multiple definition of `dcache_dir_close' > fs/fs.o(.text+0x117e0): first defined here > arch/i386/oprofile/oprofile.o(.text+0x1430): In function `dcache_dir_open': > : multiple definition of `dcache_dir_open' > fs/fs.o(.text+0x117a0): first defined here > arch/i386/oprofile/oprofile.o(.text+0x1490): In function `dcache_dir_lseek': > : multiple definition of `dcache_dir_lseek' > fs/fs.o(.text+0x11800): first defined here > arch/i386/oprofile/oprofile.o(.text+0x264): In function > `__free_cpu_buffers': > : undefined reference to `cpu_possible' > arch/i386/oprofile/oprofile.o(.text+0x2a5): In function > `alloc_cpu_buffers': > : undefined reference to `cpu_possible' > arch/i386/oprofile/oprofile.o(.text+0x902): In function `sync_cpu_buffers': > : undefined reference to `cpu_possible' > arch/i386/oprofile/oprofile.o(.text+0x19ab): In function > `oprofile_reset_stats': > : undefined reference to `cpu_possible' > arch/i386/oprofile/oprofile.o(.text+0x1a2d): In function > `oprofile_create_stats_files': > : undefined reference to `cpu_possible' > make[1]: *** [kallsyms] Error 1 > make[1]: Leaving directory `/usr/src/linux- 2.4.20-8' > make: *** [vmlinux] Error 2 > > > > any solutions ??? > > > > Regards > > > > |
From: Puneet Goel <puneet.maillist@gm...> - 2005-12-26 15:01:25
|
HI, I am getting some problem while compiling my Redhat 9 kernel 2.4.20 #cd /usr/src/linux #make menuconfig I enabled OProfile in the profiling menu and set CONFIG_PROFILING=3Dy and CONFIG_OPROFILE=3Dy in the .config file. Also enabled Local APIC and IO-API= C in the "Processor type and features" menu. #make dep #make bzImage Now i am getting errors: arch/i386/oprofile/oprofile.o(.text+0x1470): In function `dcache_dir_close'= : : multiple definition of `dcache_dir_close' fs/fs.o(.text+0x117e0): first defined here arch/i386/oprofile/oprofile.o(.text+0x1430): In function `dcache_dir_open': : multiple definition of `dcache_dir_open' fs/fs.o(.text+0x117a0): first defined here arch/i386/oprofile/oprofile.o(.text+0x1490): In function `dcache_dir_lseek'= : : multiple definition of `dcache_dir_lseek' fs/fs.o(.text+0x11800): first defined here arch/i386/oprofile/oprofile.o(.text+0x264): In function `__free_cpu_buffers': : undefined reference to `cpu_possible' arch/i386/oprofile/oprofile.o(.text+0x2a5): In function `alloc_cpu_buffers'= : : undefined reference to `cpu_possible' arch/i386/oprofile/oprofile.o(.text+0x902): In function `sync_cpu_buffers': : undefined reference to `cpu_possible' arch/i386/oprofile/oprofile.o(.text+0x19ab): In function `oprofile_reset_stats': : undefined reference to `cpu_possible' arch/i386/oprofile/oprofile.o(.text+0x1a2d): In function `oprofile_create_stats_files': : undefined reference to `cpu_possible' make[1]: *** [kallsyms] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4.20-8' make: *** [vmlinux] Error 2 any solutions ??? Regards |
From: John Levon <levon@mo...> - 2005-12-24 01:29:10
|
On Fri, Dec 23, 2005 at 11:47:34AM -0800, krishna ramachandran wrote: > ./configure --with-linux=/usr/src/linux-2.4.19.SuSE/ Read the FAQ. Kernels from distributions are supported only by those companies, not us. john |
From: krishna ramachandran <ramach1776@ya...> - 2005-12-23 19:47:42
|
I am trying to setup oprofile version 0.9.1 on linux 2.4 Linux linux 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i686 Configured using, ./configure --with-linux=/usr/src/linux-2.4.19.SuSE/ make install went fine and the module (kernel) is installed /lib/modules/2.4.19-4GB/oprofile/oprofile.o When I start oprofile using opcontrol --init I get , cat: /proc/sys/dev/oprofile/cpu_type: No such file or directory ls: /proc/sys/dev/oprofile/: No such file or directory Unable to open cpu_type file for reading Make sure you have done opcontrol --init cpu_type 'unset' is not valid the directory /proc/sys/dev/oprofile/ does not exist. Can you help Krishna __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com |
From: Yao Fei Zhu <walkinair@cn...> - 2005-12-22 10:34:40
|
John Levon wrote: >On Fri, Dec 16, 2005 at 05:04:15PM -0600, Maynard Johnson wrote: > > > >>In fact, this first iteration of categorizing obd.h was done simply by >>looking at what the Eclipse-OProfile plug-in uses. Of course, the >> >> > >If Eclipse already has its own methods for converting a file offset to a >meaningful symbol+offset, then exporting this makes sense as a low-level >API. > > As I know about Eclipse Oprofile Plug-in, yes, it does have some methods to converting file offset to meaningful symbol+offset info, but, they are not complete and correct (Please correct me if I am wrong). For example, it lacks handling of opd_header.anon_start to set a correct start_offset value, and it lacks sufficient ppc64 support of synthesizing ppc64 target's symbols table. These two things are difficult for Eclipse plug-in developers to deal with if they have little knowledge of oprofile internal data structure, bfd library or ppc64 architecture specifics. And I really appreciate if oprofile can hide these things in background from users or tool developers. As what APIs oprofile could/should export, I feel three categories API are usful, 1. low-level API, the API to get the configuration environment of oprofile, and to get raw profiling data from oprofile sample files, now it is mainly located in directory libdb and libop. a. Arch specifics, CPU type, counters, events and counter_events_map. b. OS related, sample files directory, log file, etc. c. oprofile's sample file layout and internal data structure methods to create sample files list, to analyze sample file names, to build the sample files hierarchy. methods to analyze sample file's data structure, such as header, nodes table, hash table. methods to get offset and counts list from sample file, user input the file name, and get the list of <offset, count> pair. With these information, user can do whatever he likes, using bfd library to get symbols, get source lines info, or disassemble binary code to see the instruction details. With the evolution of oprofile, this API is variable to some degree. 2. high-level API, the API to get post processing results, I see this API as an abstract layer, through this API, user can build a profiling hierarchy model and fetch meaningful things from it. With my little experience with oprofile and Eclipse Oprofile plug-in, I think the following profiling hierarchy model is to some degree complete and useful, oprofile CPU/counters/events/counter_event_map session (name, total <event,count> list) process (name, pid, <event,count> list) thread (tid, <event,count> list) dep module (name, <event, count> list) symbol (name, <event, count> list) symbol binary codes occoured sample offset source lines count process ... session ... ... ... So, in order to build this profiling data model, the following methods should provided by oprofile, a. methods to get the CPU type, event, counter and its realtionship map. b. methods to get sample offsets and count from sample files. c. methods to wrapping BFD related opreations, such as retrieve symbol table, binary contents and debug info from object files. 3. utility API When browsing OProfile source code, I find that some utility class objects or functions are very useful to developers, such as cverb for debug use, bfd support, string filter, command option processing, etc. This API can be a complementary API to the low-level API, developers can use it or not. >regards >john > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >oprofile-list mailing list >oprofile-list@... >https://lists.sourceforge.net/lists/listinfo/oprofile-list > > > |
From: John Levon <levon@mo...> - 2005-12-22 00:20:56
|
On Wed, Dec 21, 2005 at 01:20:23PM -0600, Yeh, Jason wrote: > We are currently looking into the Oprofile API and contributing the > changes we made for Java profiling. However, we are not ready to submit > patches yet. Hopefully, we will be able to contribute to the Oprofile > community real soon. That's great to hear. regards, john |
From: Yeh, Jason <jason.yeh@am...> - 2005-12-21 21:30:12
|
CodeAnalyst interfaces with Oprofile in the ways similar to how opreport uses libpp. Raw data is not used by CodeAnalyst. Instead it uses processed data through linking with libpp. Here are two ways that CodeAnalyst uses libpp to access data of current profile. The snippets of the code are at the end of this email for less cluttering: I. Use Oprofile's post processing code to generates summary in the following manner: 1. Create profile_spec. 2. Generate a list of sample files. 3. Arrange sample files into profile classes. 4. Create summary_container from profile classes. 5. CodeAnalyst saves the summary. II. Use Oprofile's post processing code to retrieve the results for each binary file in terms of symbols: 1. Create profile_spec. 2. Generate a list of sample files. 3. Arrange sample files into profile classes. 4. Invert profile classes. 5. For each inverted profile class add symbols into one profile_container. 6. Select all symbols from profile_container 7. Sort the symbols by file name and by reverse sort.=20 8. For each symbol, CodeAnalyst saves the data. If this level of API is believed to be practical and viable, I can go through headers in libpp in the same fashion Maynard Johnson has done for libdb/odb.h. Regards, Jason /****** Code segment for case 1 *****/ profile_spec const spec =3D profile_spec::create (non_options, extra_found_images); list < string > sample_files; try { sample_files =3D spec.generate_file_list (exclude_dependent, EXCLUDE_CG_DATA); m_mod_classes =3D arrange_profiles (sample_files, merge_by); } catch (...) { ... } summary_container summaries (m_mod_classes.v); // Store the count into the app_sample_map vector < app_summary >::const_iterator it =3D summaries.apps.begin = (); for (; it !=3D summaries.apps.end (); it++) { .... } /***** Code segment of case 2 *****/ profile_spec const spec =3D profile_spec::create (non_options, extra_found_images); list < string > sample_files; try { sample_files =3D spec.generate_file_list (exclude_dependent, EXCLUDE_CG_DATA); } catch (...) { ... } addr_classes =3D arrange_profiles (sample_files, merge_by); // Don't need debug info, but need details profile_container samples (false, true); list < inverted_profile > iprofiles =3D invert_profiles (options::archive_path, addr_classes, options::extra_found_images); list < inverted_profile >::iterator it =3D iprofiles.begin (); list < inverted_profile >::iterator const end =3D iprofiles.end (); for (; it !=3D end; ++it) { try { populate_for_image (options::archive_path, samples, *it, options::symbol_filter); } catch(...) { ... } } profile_container::symbol_choice choice; choice.threshold =3D 0; symbol_collection symbols =3D samples.select_symbols (choice); options::sort_by.sort (symbols, options::reverse_sort, options::long_filenames); symbol_collection::const_iterator sit =3D symbols.begin (); symbol_collection::const_iterator send =3D symbols.end (); for (; sit !=3D send; sit++) { .... } |
From: Yeh, Jason <jason.yeh@am...> - 2005-12-21 19:21:05
|
There has been some discussion of CodeAnalyst here. I would like to try to clarify some questions and comments posted to list. 1. also seems to require an entire qt3 source tree - why? It does not require qt3 source, but it requires qt- development tools (uic, moc), qt3 library and headers. 2. They include 4 different versions of oprofile, why? CodeAnalyst includes 4 versions of Oprofile to support distributions that the default kernels have difficulties working with downloaded version of Oprofile. The=20 3. Why CodeAnalyst has not contributed back to the community? There are couple reasons behind this. The GUI was ported from Windows. After porting the GUI from Windows we realize that the flow of the GUI does not work well under Linux, and also that the GUI does not provide all that much more usefulness then the command line. Command line can achieve similar tasks with much less labor. We are hesitant to try to contribute something that does not really add functionality back into Oprofile. We are currently looking into the Oprofile API and contributing the changes we made for Java profiling. However, we are not ready to submit patches yet. Hopefully, we will be able to contribute to the Oprofile community real soon. Jason -----Original Message----- From: oprofile-list-admin@... [mailto:oprofile-list-admin@...] On Behalf Of Andrew Grover Sent: Tuesday, December 20, 2005 8:14 PM To: Harry Mangalam Cc: oprofile-list@... Subject: Re: GOP (a simple OProfile GUI) 0.2 now available On 12/20/05, Harry Mangalam <hjm@...> wrote: > I can d/l it but the included configure system is broken (at least 3 missing > files) so I can't build it without more effort than I'm willing to put in just > yet - also seems to require an entire qt3 source tree - why?! ugh.. I was finally able to DL it and compile it, with some difficulty. They include 4 different versions of oprofile, why? The GUI appears to have src-level profiling and support for configuring 4 timers etc. Is this kinda an AMD version of VTune? Have you been able to try GOP? It is very different from CodeAnalyst in its approach to encapsulating oprofile, the users it targets, and the lack of complexity in the GUI and code. I do think that source-level profiling and callgraphs are features worth adding to GOP, as well as using the OProfile API when it is finalized. So, no features OProfile doesn't already have -- just making them more accessible via a GUI. -- Andy ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ oprofile-list mailing list oprofile-list@... https://lists.sourceforge.net/lists/listinfo/oprofile-list |
From: Rob Fowler <rjf@ri...> - 2005-12-21 06:54:11
|
>Date: Tue, 20 Dec 2005 18:21:00 -0800 >From: Andrew Grover <andy.grover@...> >To: John Levon <levon@...> >Subject: Re: Would it be helpful to oprofile users if oprofile can generate XML >format output? >cc: Yao Fei Zhu <walkinair@...>, oprofile-list@... > >On 11/28/05, John Levon <levon@...> wrote: > >> On Tue, Nov 29, 2005 at 03:27:25AM +0800, Yao Fei Zhu wrote: >> >> ><>>> > Another advantage I think of XML output file is that it has wider usage >>>> > than archive created by oparchive. > >> >> Simple answer: yes, we really want this. > > >Yes yes yes... > >-- Andy Our group currently has internal versions of oprofile and a conversion tool intended to make oprofile use reasonable by non-root users and to get data into the XML format used by HPCToolkit. We're doing internal testing and documentation right now, but it should be ready to be propagated back to the community in a couple of weeks. All of the oprofile tools that need it have been modified to take a --session-dir argument. This causes the demon to write things into more useful locations than /var. There are two reasons we can't just oparchive. First, on a cluster with diskless nodes, /var is in a RAM file system and memory is precious, so the outputs need to be directed to some network-mounted file system. Second, even on clusters with disks on compute nodes, the user usually doesn't have access to the node, much less /var on the local disk, after his job has run. Thus, we need to put the data immediately in a place where a non-root user can analyze it. Conversion to XML is done is two stages. We wrote a converter, currently with the unimaginative name "ophpctoolkit", that reads oprofile binary archive and outputs an equivalent in the binary format generated by hpcrun. The second stage uses hpcprof to extract sample files in the XML format that we use for profiles. We didn't want to duplicate any of the functionality of hpcprof into ophpctoolkit because this simplifies our maintenance problem Used "by hand" by an ordinary user, a session might look like: 1> mkdir /scratch/myrun 2> sudo opcontrol --session-dir=/scratch/myrun --start --event= ... 3> myprogram <myprogram's args> 4> sudo opcontrol --shutdown 5> opreport --session-dir=/scratch/myrun 6> ophpctoolkit --session-dir=/scratch/myrun/ -o myworkingfile 7> hpcprof -p myprogram myworkingfile >myprogram.pxml 8> hpcprof -p vmlinux myworkingfile >vmlinux.pxml 9> hpcprof -p some_program_myprogram_spawned myworkingfile >foo.pxml 8> ... and the rest of the hpctoolkit stuff. Notes: We intend that steps 1-4 would usually be done by a wrapper script that checks permissions and ensures that the system is left in a reasonable state when the user is done. Note that because oprofile will capture data from both the user's program and from everything "competing" with it, this is suitable only for development systems with a "friendly" set of users. On a cluster, a wrapper would be executed by the cluster scheduler running as root and it would do the necessary permission checks, create and use sub-directory for each node, and chown and chmod the output directories to be owned by the user. Instead of just one program, the "payload" of the wrapper would often be a script that executes a complicated workflow, maybe by starting up an interactive sub-shell. Running opreport here is not necessary, but is an example of good practice. It gives the user an idea of which images, in addition to his own program, significantly impacted performance. Some of these may have been part of the workflow. Some may be competing activities that impacted the execution. This is a big advantage of oprofile over hpcrun. The sequence of hpcprof executions extracts an XML file for each of these images. Everything from line 7 onward would typically be embedded in a hpctoolkit script. For example, pointing hpcquick at myworkingfile extracts XML for all of the images in in myworkingfile, so we can suck the entire oprofile archive up into our toolchain for analysis. Because profiles can be huge, we have a pretty lean XML format for profile data. See http://hipersoft.rice.edu/hpctoolkit/documentation/HPCToolkit/doc/dtd_profile.html for a description. -- Rob Fowler |
From: Harry Mangalam <hjm@ta...> - 2005-12-21 02:50:31
|
On Tuesday 20 December 2005 18:13, Andrew Grover wrote: > On 12/20/05, Harry Mangalam <hjm@...> wrote: > > I can d/l it but the included configure system is broken (at least 3 > > missing files) so I can't build it without more effort than I'm willing > > to put in just yet - also seems to require an entire qt3 source tree - > > why?! ugh.. > > I was finally able to DL it and compile it, with some difficulty. They > include 4 different versions of oprofile, why? The GUI appears to have > src-level profiling and support for configuring 4 timers etc. Is this > kinda an AMD version of VTune? I tend to agree - it seems needlessly complex for what it gives you. > Have you been able to try GOP? It is very different from CodeAnalyst > in its approach to encapsulating oprofile, the users it targets, and > the lack of complexity in the GUI and code. No, but I'll probably try it over the break. > I do think that source-level profiling and callgraphs are features > worth adding to GOP, as well as using the OProfile API when it is > finalized. So, no features OProfile doesn't already have -- just > making them more accessible via a GUI. Great - I look forward to trying it. -- Cheers, Harry Harry J Mangalam - 949 856 2847 (vox; email for fax) - hjm@... <<plain text preferred>> |
From: Andrew Grover <andy.grover@gm...> - 2005-12-21 02:21:03
|
On 11/28/05, John Levon <levon@...> wrote: > On Tue, Nov 29, 2005 at 03:27:25AM +0800, Yao Fei Zhu wrote: > > > Another advantage I think of XML output file is that it has wider usage > > than archive created by oparchive. > > Simple answer: yes, we really want this. Yes yes yes... -- Andy |
From: Andrew Grover <andy.grover@gm...> - 2005-12-21 02:13:56
|
On 12/20/05, Harry Mangalam <hjm@...> wrote: > I can d/l it but the included configure system is broken (at least 3 miss= ing > files) so I can't build it without more effort than I'm willing to put in= just > yet - also seems to require an entire qt3 source tree - why?! ugh.. I was finally able to DL it and compile it, with some difficulty. They include 4 different versions of oprofile, why? The GUI appears to have src-level profiling and support for configuring 4 timers etc. Is this kinda an AMD version of VTune? Have you been able to try GOP? It is very different from CodeAnalyst in its approach to encapsulating oprofile, the users it targets, and the lack of complexity in the GUI and code. I do think that source-level profiling and callgraphs are features worth adding to GOP, as well as using the OProfile API when it is finalized. So, no features OProfile doesn't already have -- just making them more accessible via a GUI. -- Andy |
From: Harry Mangalam <hjm@ta...> - 2005-12-20 23:24:32
|
I can d/l it but the included configure system is broken (at least 3 missing files) so I can't build it without more effort than I'm willing to put in just yet - also seems to require an entire qt3 source tree - why?! ugh.. hjm Andrew Grover wrote: > On 12/20/05, Harry Mangalam <hjm@...> wrote: >> This may be OT a bit, but what are the diffs between GOP and the AMD-supplied >> CodeAnalyst Performance Analyzer GUI which seems to ride atop oprofile? > > Hmm! I'd never heard of this. I view GOP as a way to make OProfile > more accessible to users who would otherwise a) not do any profiling > or b) use sysprof. I tried to D/L CodeAnalyst to take a look but hit a > webpage error, so I don't know how it compares. > > -- Andy > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id865&opclick |
From: Andrew Grover <andy.grover@gm...> - 2005-12-20 22:51:16
|
On 12/20/05, Harry Mangalam <hjm@...> wrote: > This may be OT a bit, but what are the diffs between GOP and the AMD-supp= lied > CodeAnalyst Performance Analyzer GUI which seems to ride atop oprofile? Hmm! I'd never heard of this. I view GOP as a way to make OProfile more accessible to users who would otherwise a) not do any profiling or b) use sysprof. I tried to D/L CodeAnalyst to take a look but hit a webpage error, so I don't know how it compares. -- Andy |
From: John Levon <levon@mo...> - 2005-12-20 21:53:33
|
On Tue, Dec 20, 2005 at 01:19:11PM -0800, Harry Mangalam wrote: > This may be OT a bit, but what are the diffs between GOP and the AMD-supplied > CodeAnalyst Performance Analyzer GUI which seems to ride atop oprofile? They don't seem to have any interest in community involvement at all. john |
From: Harry Mangalam <hjm@ta...> - 2005-12-20 21:24:46
|
This may be OT a bit, but what are the diffs between GOP and the AMD-supplied CodeAnalyst Performance Analyzer GUI which seems to ride atop oprofile? http://devforums.amd.com/index.php?showforum=9 I tried to get it to build on a debian system but was unable to, so I couldn't tell. <quote> AMD CodeAnalyst Performance Analyzer 2.5 is an open source front-end graphical user interface to Oprofile. </quote> Is there any reason NOT to contribute more functionality to AMD's effort as opposed to another one? (As long as it was CPU-neutral...) hjm Andrew Grover wrote: > I've done a little more hacking on GOP, a simple GUI frontend for OProfile. > > http://groveronline.com/software/gop-0.2.tar.gz > > A lot of bugs were fixed, the menus were cleaned up, and the > preferences dialog now remembers additional image paths. > > Regards -- Andy > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id865&opclick |
From: Harry Mangalam <hjm@ta...> - 2005-12-20 18:08:13
|
FAQ contribution: This is probably longer and less specific than what you wanted, but I had to write up this little HOWTO stanza for our own group, so you're welcome to use whatever part of it you'd like for inclusion or clarification in your own docs. The end of the Oprofile section has a bit that discusses the conflict between Oprofile and the PAPI/HPCToolkit approach. If I've misrepresented oprofile, please let me know - I'm but a simple user. FAQ entry for the usage & interaction of PAPI & Oprofile Many Linux machines will be set up to use both oprofile (now available in the 2.6 kernel source as a module [CONFIG_OPROFILE=m]) and tools which require the PAPI API to do performance profiling (such as the HPCToolkit's hpcrun [http://www.hipersoft.rice.edu/hpctoolkit/]). The latter requires a kernel source patch and recompile to enable the PAPI API under Linux, as well as the compilation of the 'perfctr' kernel module. I believe that other SW that uses the PAPI API under Linux (such as U.Orgegon's sophisticated Tuning and Analysis Utilities (tau [http://www.cs.uoregon.edu/research/tau/home.php]) also uses the perfctr module. Many distribution kernels come with the oprofile module enabled; none that I'm aware of come with the PAPI patches applied and usable (a shame - it's very useful to developers). Both software approaches are quite useful and yield complementary (& some overlapping) information and both have distinct advantages. However, the two approaches cannot be used successively without some caution. Since both kernel modules access some of the same resources, one must be unloaded before the other is used. In using oprofile, the web site is a good place to start - the documentation and especially the examples are extremely useful. [http://oprofile.sourceforge.net/docs] NB: The Ubuntu distro that I use has no root user, so all root commands are prefaced with 'sudo' to indicate a root-requiring command. On those systems with root users, you could do this as root or even enable a root shell on a Ubuntu-like distro with 'sudo bash'. Oprofile first requires the module loading: $ sudo modprobe oprofile Second, initialize the 'oprofiled' daemon and start it collecting info. This is a different approach from the HPCToolkit and allows oprofile to analyze not only the application under investigation but the entire system for the time being profiles including the kernel itself. The HPCToolkit is specific for particular applications and as such does not require a daemon running. $ sudo opcontrol --vmlinux=/path/to/vmlinux Or when you don't have a vmlinux or don't want to profile the kernel $ opcontrol --no-vmlinux NOTE that this is the UNCOMPRESSED linux elf executable, not the typical vmlinuz compressed boot sector that is installed in the /boot dir In the case of my machine: $ sudo opcontrol --vmlinux=/usr/src/linux-2.6.11/vmlinux This machine is a dual opteron. If I wanted to profile each CPU separately, I would invoke it with: $ sudo opcontrol --separate=cpu --vmlinux=/usr/src/linux-2.6.11/vmlinux to report profiling on both CPUs Note that once enabled for BOTH CPUs, you have to explicitly shut it off for succeeding runs where you want the results pooled for both CPUs. $ sudo opcontrol --separate=none --vmlinux=/usr/src/linux-2.6.11/vmlinux Next, start the profiling with: $ sudo opcontrol --start When ready to collect info, do a 'sudo ls' to init the timeout on the sudo command so later ones don't ask for passwords, then for an application (an executable called ncbo in the following example) and assuming that it has been compiled with the '-g' flag: # first reset the counters: $ sudo opcontrol --reset # execute the command $ /home/hjm/nco/bin/ncbo -h -O --op_typ='-' -p /home/hjm/nco_bm \ ipcc_dly_T85.nc ipcc_dly_T85_00.nc /home/hjm/nco_bm/ipcc.diff.nc # this command runs for > 60s, important as it's a statistical profiler # when the program ends, dump the collected statistics $ opreport --exclude-dependent --demangle=smart --symbols > \ oprofile.report.full.ncbo The above stanza is meant to be run as a shell or moused into a shell window so there is minimal delay from resetting the counters to running the proram to generating the output. This ensures that the profiling data is specific to the application that is running. The output is a human-readable text file that will give you the time spent in each function. The poll_idle time is that time which the CPU(s) has spent doing NOTHING. ie idling. For a lightly loaded dual-CPU machine, you would expect to obtain about 50% in poll_idle running a single serial job. Cleaning up after Oprofile. Since Oprofile runs as a daemon, it adds a very small amount of CPU and memory overhead to a running system. To remove that overhead, you have to explicitly kill the daemon: $ sudo opcontrol --shutdown This next part is not well-documented and only causes a problem if you want to run a PAPI-based profiler such as hpcrun. You MUST remove the oprofile module and this cannot be done via the usual 'rmmod oprofile' approach. There is a specific command to do it: $ opcontrol --deinit If the oprofile module is loaded and you try to run 'hpcrun' (even to get a list of available options), you'll get an unhelpful error like this: $ hpcrun -L (pid 27342): PAPI library initialization failure - expected version 50397184, dynamic library was version -3. Aborting. This is diagnostic (I believe) that the oprofile module is still loaded and that the perfctr and oprofile modules are fighting over the CPU. Using hpcrun: ============= Don't forget that in order for the hpcrun to work, the perftr module has to be modprobe-loaded AND /dev/perfctr has to be chmod to 644. Using the HPCToolkit: first make sure that the oprofile module is not loaded: $ lsmod |grep oprofile should return nothing. If it gives you an indication that the oprofile module IS loaded, unload it with the command: $ sudo opcontrol --deinit then load the perfctr module to allow the PAPI API access to the hardware counters. $ modprobe perfctr After this, it is relatively straightforward. Anything you want to profile, just run it behind the 'hpcrun' command: $hpcrun (options) -- home/hjm/nco/bin/ncbo -h -O --op_typ='-' -p /home/hjm/nco_bm \ ipcc_dly_T85.nc ipcc_dly_T85_00.nc /home/hjm/nco_bm/ipcc.diff.nc the (options) are typically a set of hardware counters you want to access during the run. On an Opteron, the available options can be got by running: $ hpcrun -L |grep Yes 517 $ hpcrun -L |grep Yes PAPI_L2_DCM Yes Level 2 data cache misses () PAPI_L2_ICM Yes Level 2 instruction cache misses () PAPI_FPU_IDL Yes Cycles floating point units are idle () PAPI_TLB_DM Yes Data translation lookaside buffer misses () PAPI_TLB_IM Yes Instruction translation lookaside buffer misses () PAPI_L1_LDM Yes Level 1 load misses () PAPI_L1_STM Yes Level 1 store misses () PAPI_L2_LDM Yes Level 2 load misses () PAPI_L2_STM Yes Level 2 store misses () PAPI_STL_ICY Yes Cycles with no instruction issue () PAPI_HW_INT Yes Hardware interrupts () PAPI_BR_TKN Yes Conditional branch instructions taken () PAPI_BR_MSP Yes Conditional branch instructions mispredicted () PAPI_TOT_INS Yes Instructions completed () PAPI_FP_INS Yes Floating point instructions () PAPI_BR_INS Yes Branch instructions () PAPI_VEC_INS Yes Vector/SIMD instructions () PAPI_RES_STL Yes Cycles stalled on any resource () PAPI_TOT_CYC Yes Total cycles () PAPI_L2_DCH Yes Level 2 data cache hits () PAPI_L1_DCA Yes Level 1 data cache accesses () PAPI_L2_DCR Yes Level 2 data cache reads () PAPI_L2_DCW Yes Level 2 data cache writes () PAPI_L2_ICH Yes Level 2 instruction cache hits () PAPI_L1_ICA Yes Level 1 instruction cache accesses () PAPI_L1_ICR Yes Level 1 instruction cache reads () PAPI_FML_INS Yes Floating point multiply instructions () PAPI_FAD_INS Yes Floating point add instructions () PAPI_FP_OPS Yes Floating point operations () these options can be requested by inserting them into the (options) space, for example, as: $ hpcrun -e PAPI_TOT_CYC:32767 -e PAPI_FP_OPS:32767 -e PAPI_FP_INS:32767\ -e PAPI_HW_INT:32767 -e PAPI_L2_DCM:32767 -- <command to profile> [don't forget the '--' separator between the hpcrun command chain and the application] hpcrun will profile EVERYTHING that results from the <command to profile> so if it's a shell command, it will profile every subcommand in the shell, giving each its own output file in the form of: <app_name>.PAPI_TOT_CYC.clay.ess.uci.edu.10137.0 The output files you're interested in can be processed into something usable with 'hpcquick', a perl script that calls some other HPC tools to generate the XML DB (in its own subdirectory) that the java browser 'hpcviewer' needs. # src location hpcrun output file to process vvvvvvv vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv hpcquick -I src/nco -P ncwa.PAPI_TOT_CYC.clay.ess.uci.edu.10137.0 # view the results via java hpcviewer hpcviewer # and open the './hpcquick.dbxxx/hpcquick.hpcviewer' file. This will open a java-based source and data browser that can show you where your application is spending time. John Levon wrote: > On Thu, Dec 15, 2005 at 07:03:54PM -0800, Harry Mangalam wrote: > >> Does this mean that on kernels >2.5, the module can be unloaded safely >> even if it IS an SMP system? > > Yes. Use opcontrol --deinit (or unmount oprofilefs and unload directly). > > john > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click |
From: Stephane Eranian <eranian@hp...> - 2005-12-20 11:49:25
|
Hello, I have been looking at the Oprofile source from 2.6.15-rc6 for i386 and I have a question about the NMI setup has done by nmi_setup() in nmi_int.c. The call to reserve_lapic_nmi() is made once one some CPU. That is enough to disable the LAPIC NMI watchdog. But this is not enough to stop the performance counters on all CPUS. The NMI watchdog is operating on all CPUS and is setup in setup_local_APIC(). Yet the disable_lapic_nmi() will be invoked only on one CPU. That means that On all but one CPU, the perf counters are still running and can possibly interrupt while OProfile is setting itself up. I have reported this NMI logic problem on lkml in this message: http://marc.theaimsgroup.com/?l=linux-kernel&m=113500459412560&w=3 What is your take on this? Thanks. -- -Stephane |
From: madan mohan <madsinrec@ya...> - 2005-12-20 07:50:22
|
Hi, I'm using oprofile-0.9.1. I'm trying to cross compile oprofile for ARM9 on Linux kernel 2.6.12. I tried with the ./configure --with-kernel-support --host=arm-none-linux-gnueabi --build=i686-pc-linux-gnu I'm getting the error as : checking for perfmonctl... no checking for poptGetContext in -lpopt... no configure: error: popt library not found Do You have any idea on this? Thanks & Regards, Madan. Send instant messages to your online friends http://in.messenger.yahoo.com |
From: Andrew Grover <andy.grover@gm...> - 2005-12-19 12:36:36
|
I've done a little more hacking on GOP, a simple GUI frontend for OProfile. http://groveronline.com/software/gop-0.2.tar.gz A lot of bugs were fixed, the menus were cleaned up, and the preferences dialog now remembers additional image paths. Regards -- Andy |