From: SourceForge.net <no...@so...> - 2007-01-11 15:46:25
|
Bugs item #1633312, was opened at 2007-01-11 15:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rob Bradford (robster) Assigned to: Nobody/Anonymous (nobody) Summary: XML output attributes symbols to incorrect module Initial Comment: The XML output subdivides each image (<binary></binary>) into modules (<module></module>) and includes the symbol counts for the symbol within that module. Unfortunately it seems to attribute the symbols of the program itself with one of the modules, e.g. the C library. In the attached XML file the symbols within oprofiled are are attributed to the C library. I believe that these should be included outside of a <module></module> block. On a related note why is the module (e.g. shared librarie)s, associated with the binary rather than the symbol. Surely a symbol is part of a shared library and thus used by the binary rather than the other way around. Regards, Rob ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 |
From: SourceForge.net <no...@so...> - 2007-01-11 22:37:25
|
Bugs item #1633312, was opened at 2007-01-11 07:46 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rob Bradford (robster) Assigned to: Nobody/Anonymous (nobody) Summary: XML output attributes symbols to incorrect module Initial Comment: The XML output subdivides each image (<binary></binary>) into modules (<module></module>) and includes the symbol counts for the symbol within that module. Unfortunately it seems to attribute the symbols of the program itself with one of the modules, e.g. the C library. In the attached XML file the symbols within oprofiled are are attributed to the C library. I believe that these should be included outside of a <module></module> block. On a related note why is the module (e.g. shared librarie)s, associated with the binary rather than the symbol. Surely a symbol is part of a shared library and thus used by the binary rather than the other way around. Regards, Rob ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-11 14:37 Message: Logged In: NO Are you saying that there is a <symbol> that is defined within the program, and not in a <module> and that it is being inserted in the list of symbols associated with the C library? If so could you give me a specific instance of this in your example? In your "related note" I'm not sure what you mean by "associated with". A <symbol> is nested inside of <module> because it is the <module> that defines the <symbol>. The <module> is nested inside of <binary> because a program <binary> can link in (statically or dynamically) multiple libraries. It sounds like you are assigning a different meaning to <binary> than was intended. It is just a syntactic container for <module>s and can represent either a program or a library. The reason why a <binary> can be a library is in the case where there is no sampling data for the program binary, only for the libraries that it uses. A <symbol> is an instance of a symbol(since a symbol may be defined in multiple libraries) and contains its sample data. e.g. you could have lib1 and lib2 both define init() and each instance of "init" would have different sample data that must be separated. There is an XML schema file in doc/opreport.xsd that attempts to clarify these elements. If I've misunderstood your point please clarify for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 |
From: SourceForge.net <no...@so...> - 2007-01-12 00:46:30
|
Bugs item #1633312, was opened at 2007-01-11 15:46 Message generated for change (Comment added) made by dcnomura You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rob Bradford (robster) Assigned to: Nobody/Anonymous (nobody) Summary: XML output attributes symbols to incorrect module Initial Comment: The XML output subdivides each image (<binary></binary>) into modules (<module></module>) and includes the symbol counts for the symbol within that module. Unfortunately it seems to attribute the symbols of the program itself with one of the modules, e.g. the C library. In the attached XML file the symbols within oprofiled are are attributed to the C library. I believe that these should be included outside of a <module></module> block. On a related note why is the module (e.g. shared librarie)s, associated with the binary rather than the symbol. Surely a symbol is part of a shared library and thus used by the binary rather than the other way around. Regards, Rob ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-12 00:46 Message: Logged In: YES user_id=1689878 Originator: NO I forgot to login before posting the previous response ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-11 22:37 Message: Logged In: NO Are you saying that there is a <symbol> that is defined within the program, and not in a <module> and that it is being inserted in the list of symbols associated with the C library? If so could you give me a specific instance of this in your example? In your "related note" I'm not sure what you mean by "associated with". A <symbol> is nested inside of <module> because it is the <module> that defines the <symbol>. The <module> is nested inside of <binary> because a program <binary> can link in (statically or dynamically) multiple libraries. It sounds like you are assigning a different meaning to <binary> than was intended. It is just a syntactic container for <module>s and can represent either a program or a library. The reason why a <binary> can be a library is in the case where there is no sampling data for the program binary, only for the libraries that it uses. A <symbol> is an instance of a symbol(since a symbol may be defined in multiple libraries) and contains its sample data. e.g. you could have lib1 and lib2 both define init() and each instance of "init" would have different sample data that must be separated. There is an XML schema file in doc/opreport.xsd that attempts to clarify these elements. If I've misunderstood your point please clarify for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 |
From: SourceForge.net <no...@so...> - 2007-01-12 09:39:35
|
Bugs item #1633312, was opened at 2007-01-11 15:46 Message generated for change (Comment added) made by robster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rob Bradford (robster) Assigned to: Nobody/Anonymous (nobody) Summary: XML output attributes symbols to incorrect module Initial Comment: The XML output subdivides each image (<binary></binary>) into modules (<module></module>) and includes the symbol counts for the symbol within that module. Unfortunately it seems to attribute the symbols of the program itself with one of the modules, e.g. the C library. In the attached XML file the symbols within oprofiled are are attributed to the C library. I believe that these should be included outside of a <module></module> block. On a related note why is the module (e.g. shared librarie)s, associated with the binary rather than the symbol. Surely a symbol is part of a shared library and thus used by the binary rather than the other way around. Regards, Rob ---------------------------------------------------------------------- >Comment By: Rob Bradford (robster) Date: 2007-01-12 09:39 Message: Logged In: YES user_id=44495 Originator: YES Thank you for your quick response: "Are you saying that there is a <symbol> that is defined within the program, and not in a <module> and that it is being inserted in the list of symbols associated with the C library? If so could you give me a specific instance of this in your example?" Yes. This is a report of 'oprofiled'. e.g. Symbol with id=36 is is_sfile_anon as is defined in the program under analysis: <symboldata id="36" name="is_sfile_anon" file="/home/rob/o-hand/oprofile/oprofile-cvs-20070106/oprofile/daemon/opd_sfile.c" line="487" startingaddr="0804a9d0"/> This symbol is however included within the <module></module> block for the /lib/tls/i686/cmov/libc-2.5.so (line 161). Thank you for clarifying my other query. ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-12 00:46 Message: Logged In: YES user_id=1689878 Originator: NO I forgot to login before posting the previous response ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-11 22:37 Message: Logged In: NO Are you saying that there is a <symbol> that is defined within the program, and not in a <module> and that it is being inserted in the list of symbols associated with the C library? If so could you give me a specific instance of this in your example? In your "related note" I'm not sure what you mean by "associated with". A <symbol> is nested inside of <module> because it is the <module> that defines the <symbol>. The <module> is nested inside of <binary> because a program <binary> can link in (statically or dynamically) multiple libraries. It sounds like you are assigning a different meaning to <binary> than was intended. It is just a syntactic container for <module>s and can represent either a program or a library. The reason why a <binary> can be a library is in the case where there is no sampling data for the program binary, only for the libraries that it uses. A <symbol> is an instance of a symbol(since a symbol may be defined in multiple libraries) and contains its sample data. e.g. you could have lib1 and lib2 both define init() and each instance of "init" would have different sample data that must be separated. There is an XML schema file in doc/opreport.xsd that attempts to clarify these elements. If I've misunderstood your point please clarify for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 |
From: SourceForge.net <no...@so...> - 2007-01-12 12:16:21
|
Bugs item #1633312, was opened at 2007-01-11 15:46 Message generated for change (Comment added) made by robster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rob Bradford (robster) Assigned to: Nobody/Anonymous (nobody) Summary: XML output attributes symbols to incorrect module Initial Comment: The XML output subdivides each image (<binary></binary>) into modules (<module></module>) and includes the symbol counts for the symbol within that module. Unfortunately it seems to attribute the symbols of the program itself with one of the modules, e.g. the C library. In the attached XML file the symbols within oprofiled are are attributed to the C library. I believe that these should be included outside of a <module></module> block. On a related note why is the module (e.g. shared librarie)s, associated with the binary rather than the symbol. Surely a symbol is part of a shared library and thus used by the binary rather than the other way around. Regards, Rob ---------------------------------------------------------------------- >Comment By: Rob Bradford (robster) Date: 2007-01-12 12:16 Message: Logged In: YES user_id=44495 Originator: YES I should also add that as you can probably see this was generated with --separate=lib ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 09:39 Message: Logged In: YES user_id=44495 Originator: YES Thank you for your quick response: "Are you saying that there is a <symbol> that is defined within the program, and not in a <module> and that it is being inserted in the list of symbols associated with the C library? If so could you give me a specific instance of this in your example?" Yes. This is a report of 'oprofiled'. e.g. Symbol with id=36 is is_sfile_anon as is defined in the program under analysis: <symboldata id="36" name="is_sfile_anon" file="/home/rob/o-hand/oprofile/oprofile-cvs-20070106/oprofile/daemon/opd_sfile.c" line="487" startingaddr="0804a9d0"/> This symbol is however included within the <module></module> block for the /lib/tls/i686/cmov/libc-2.5.so (line 161). Thank you for clarifying my other query. ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-12 00:46 Message: Logged In: YES user_id=1689878 Originator: NO I forgot to login before posting the previous response ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-11 22:37 Message: Logged In: NO Are you saying that there is a <symbol> that is defined within the program, and not in a <module> and that it is being inserted in the list of symbols associated with the C library? If so could you give me a specific instance of this in your example? In your "related note" I'm not sure what you mean by "associated with". A <symbol> is nested inside of <module> because it is the <module> that defines the <symbol>. The <module> is nested inside of <binary> because a program <binary> can link in (statically or dynamically) multiple libraries. It sounds like you are assigning a different meaning to <binary> than was intended. It is just a syntactic container for <module>s and can represent either a program or a library. The reason why a <binary> can be a library is in the case where there is no sampling data for the program binary, only for the libraries that it uses. A <symbol> is an instance of a symbol(since a symbol may be defined in multiple libraries) and contains its sample data. e.g. you could have lib1 and lib2 both define init() and each instance of "init" would have different sample data that must be separated. There is an XML schema file in doc/opreport.xsd that attempts to clarify these elements. If I've misunderstood your point please clarify for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 |
From: SourceForge.net <no...@so...> - 2007-01-12 12:16:45
|
Bugs item #1633312, was opened at 2007-01-11 15:46 Message generated for change (Comment added) made by robster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rob Bradford (robster) Assigned to: Nobody/Anonymous (nobody) Summary: XML output attributes symbols to incorrect module Initial Comment: The XML output subdivides each image (<binary></binary>) into modules (<module></module>) and includes the symbol counts for the symbol within that module. Unfortunately it seems to attribute the symbols of the program itself with one of the modules, e.g. the C library. In the attached XML file the symbols within oprofiled are are attributed to the C library. I believe that these should be included outside of a <module></module> block. On a related note why is the module (e.g. shared librarie)s, associated with the binary rather than the symbol. Surely a symbol is part of a shared library and thus used by the binary rather than the other way around. Regards, Rob ---------------------------------------------------------------------- >Comment By: Rob Bradford (robster) Date: 2007-01-12 12:16 Message: Logged In: YES user_id=44495 Originator: YES I should also add that as you can probably see this was generated with --separate=lib ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 12:16 Message: Logged In: YES user_id=44495 Originator: YES I should also add that as you can probably see this was generated with --separate=lib ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 09:39 Message: Logged In: YES user_id=44495 Originator: YES Thank you for your quick response: "Are you saying that there is a <symbol> that is defined within the program, and not in a <module> and that it is being inserted in the list of symbols associated with the C library? If so could you give me a specific instance of this in your example?" Yes. This is a report of 'oprofiled'. e.g. Symbol with id=36 is is_sfile_anon as is defined in the program under analysis: <symboldata id="36" name="is_sfile_anon" file="/home/rob/o-hand/oprofile/oprofile-cvs-20070106/oprofile/daemon/opd_sfile.c" line="487" startingaddr="0804a9d0"/> This symbol is however included within the <module></module> block for the /lib/tls/i686/cmov/libc-2.5.so (line 161). Thank you for clarifying my other query. ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-12 00:46 Message: Logged In: YES user_id=1689878 Originator: NO I forgot to login before posting the previous response ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-11 22:37 Message: Logged In: NO Are you saying that there is a <symbol> that is defined within the program, and not in a <module> and that it is being inserted in the list of symbols associated with the C library? If so could you give me a specific instance of this in your example? In your "related note" I'm not sure what you mean by "associated with". A <symbol> is nested inside of <module> because it is the <module> that defines the <symbol>. The <module> is nested inside of <binary> because a program <binary> can link in (statically or dynamically) multiple libraries. It sounds like you are assigning a different meaning to <binary> than was intended. It is just a syntactic container for <module>s and can represent either a program or a library. The reason why a <binary> can be a library is in the case where there is no sampling data for the program binary, only for the libraries that it uses. A <symbol> is an instance of a symbol(since a symbol may be defined in multiple libraries) and contains its sample data. e.g. you could have lib1 and lib2 both define init() and each instance of "init" would have different sample data that must be separated. There is an XML schema file in doc/opreport.xsd that attempts to clarify these elements. If I've misunderstood your point please clarify for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 |
From: SourceForge.net <no...@so...> - 2007-01-17 19:02:29
|
Bugs item #1633312, was opened at 2007-01-11 15:46 Message generated for change (Comment added) made by dcnomura You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rob Bradford (robster) Assigned to: Nobody/Anonymous (nobody) Summary: XML output attributes symbols to incorrect module Initial Comment: The XML output subdivides each image (<binary></binary>) into modules (<module></module>) and includes the symbol counts for the symbol within that module. Unfortunately it seems to attribute the symbols of the program itself with one of the modules, e.g. the C library. In the attached XML file the symbols within oprofiled are are attributed to the C library. I believe that these should be included outside of a <module></module> block. On a related note why is the module (e.g. shared librarie)s, associated with the binary rather than the symbol. Surely a symbol is part of a shared library and thus used by the binary rather than the other way around. Regards, Rob ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-17 19:02 Message: Logged In: YES user_id=1689878 Originator: NO I have been able to reproduce the problem and am working on a fix for it. ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 12:16 Message: Logged In: YES user_id=44495 Originator: YES I should also add that as you can probably see this was generated with --separate=lib ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 12:16 Message: Logged In: YES user_id=44495 Originator: YES I should also add that as you can probably see this was generated with --separate=lib ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 09:39 Message: Logged In: YES user_id=44495 Originator: YES Thank you for your quick response: "Are you saying that there is a <symbol> that is defined within the program, and not in a <module> and that it is being inserted in the list of symbols associated with the C library? If so could you give me a specific instance of this in your example?" Yes. This is a report of 'oprofiled'. e.g. Symbol with id=36 is is_sfile_anon as is defined in the program under analysis: <symboldata id="36" name="is_sfile_anon" file="/home/rob/o-hand/oprofile/oprofile-cvs-20070106/oprofile/daemon/opd_sfile.c" line="487" startingaddr="0804a9d0"/> This symbol is however included within the <module></module> block for the /lib/tls/i686/cmov/libc-2.5.so (line 161). Thank you for clarifying my other query. ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-12 00:46 Message: Logged In: YES user_id=1689878 Originator: NO I forgot to login before posting the previous response ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-11 22:37 Message: Logged In: NO Are you saying that there is a <symbol> that is defined within the program, and not in a <module> and that it is being inserted in the list of symbols associated with the C library? If so could you give me a specific instance of this in your example? In your "related note" I'm not sure what you mean by "associated with". A <symbol> is nested inside of <module> because it is the <module> that defines the <symbol>. The <module> is nested inside of <binary> because a program <binary> can link in (statically or dynamically) multiple libraries. It sounds like you are assigning a different meaning to <binary> than was intended. It is just a syntactic container for <module>s and can represent either a program or a library. The reason why a <binary> can be a library is in the case where there is no sampling data for the program binary, only for the libraries that it uses. A <symbol> is an instance of a symbol(since a symbol may be defined in multiple libraries) and contains its sample data. e.g. you could have lib1 and lib2 both define init() and each instance of "init" would have different sample data that must be separated. There is an XML schema file in doc/opreport.xsd that attempts to clarify these elements. If I've misunderstood your point please clarify for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 |
From: SourceForge.net <no...@so...> - 2007-01-17 22:42:58
|
Bugs item #1633312, was opened at 2007-01-11 15:46 Message generated for change (Comment added) made by dcnomura You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rob Bradford (robster) Assigned to: Nobody/Anonymous (nobody) Summary: XML output attributes symbols to incorrect module Initial Comment: The XML output subdivides each image (<binary></binary>) into modules (<module></module>) and includes the symbol counts for the symbol within that module. Unfortunately it seems to attribute the symbols of the program itself with one of the modules, e.g. the C library. In the attached XML file the symbols within oprofiled are are attributed to the C library. I believe that these should be included outside of a <module></module> block. On a related note why is the module (e.g. shared librarie)s, associated with the binary rather than the symbol. Surely a symbol is part of a shared library and thus used by the binary rather than the other way around. Regards, Rob ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-17 22:42 Message: Logged In: YES user_id=1689878 Originator: NO the following is a proposed patch to oprofile/libpp/xml_utils.cpp to fix the above problem. Rob, please let me know if this solves your problem or if you have any other issues before I submit the patch to the oprofile-developers mailing list. ====================================================================================== diff -paurN ../cvs_1_12/libpp/xml_utils.cpp ./libpp/xml_utils.cpp --- ../cvs_1_12/libpp/xml_utils.cpp 2006-11-17 17:47:29.000000000 -0600 +++ ./libpp/xml_utils.cpp 2007-01-17 16:30:50.486084080 -0600 @@ -60,7 +60,7 @@ size_t get_next_event_num_pclass(size_t } -void dump_it(string const & prefix, sym_iterator it, bool want_nl = true) +void dump_symbol(string const & prefix, sym_iterator it, bool want_nl = true) { if (it == symbols_end) cverb << vxml << prefix << "END"; @@ -71,6 +71,17 @@ void dump_it(string const & prefix, sym_ } +void dump_symbols(string const & prefix, sym_iterator b, sym_iterator e) +{ + if (b == (sym_iterator)0) + return; + + for (sym_iterator it = b; it != e; ++it) + dump_symbol(prefix, it, true); +} + + + void dump_classes() { cverb << vxml << "<!-- classes dump" << endl; @@ -425,6 +436,7 @@ public: void set_lo(size_t l) { lo = l; } void set_hi(size_t h) { hi = h; } count_array_t const & get_summary() { return summary; } + void set_begin(sym_iterator b); void set_end(sym_iterator e); void add_to_summary(count_array_t const & counts); void output(ostream & out); @@ -502,7 +514,7 @@ class binary_info : public module_info { public: binary_info() { nr_modules = 0; } void output(ostream & out); - binary_info * build_binary(string const & n, sym_iterator it); + binary_info * build_binary(string const & n); void add_module_symbol(string const & module, string const & app, sym_iterator it); void close_binary(sym_iterator it); @@ -547,6 +559,14 @@ void module_info::add_to_summary(count_a summary[pclass] += counts[pclass]; } + +void module_info::set_begin(sym_iterator b) +{ + if (begin == (sym_iterator)0) + begin = b; +} + + void module_info::set_end(sym_iterator e) { if (end == (sym_iterator)0) @@ -562,10 +582,9 @@ bool module_info::is_closed(string const void module_info::dump() { - cverb << vxml << "module:class(" << lo << "," << hi << ")="; + cverb << vxml << " module:class(" << lo << "," << hi << ")="; cverb << vxml << name << endl; - dump_it(" ", begin, false); - dump_it(" .. ", end-1); + dump_symbols(" ", begin, end); } @@ -588,6 +607,9 @@ void module_info::output_summary(ostream void module_info::output_symbols(ostream & out) { + if (begin == (sym_iterator)0) + return; + for (sym_iterator it = begin; it != end; ++it) xml_out->output_symbol(out, it, lo, hi); } @@ -595,15 +617,13 @@ void module_info::output_symbols(ostream void binary_info::close_binary(sym_iterator it) { + set_end(it); if (nr_modules > 0) { module_info & m = my_modules[nr_modules-1]; m.set_end(it); // propagate module summary to binary add_to_summary(m.get_summary()); - } else { - // close binary with no modules - set_end(it); } } @@ -611,6 +631,10 @@ void binary_info::close_binary(sym_itera void binary_info::dump() { cverb << vxml << "app_name=" << name << endl; + if (begin != (sym_iterator)0) { + dump_symbols(" ", begin, end); + } + for (size_t i = 0; i < nr_modules; ++i) my_modules[i].dump(); } @@ -620,20 +644,34 @@ void binary_info:: add_module_symbol(string const & module, string const & app, sym_iterator it) { + size_t m = nr_modules; + if (module == app) { + // set begin symbol for binary if not set + set_begin(it); + + if (m > 0) { + // close out current module + module_info & mod = my_modules[m-1]; + mod.set_end(it); + add_to_summary(mod.get_summary()); + } + // no module, so add symbol count to binary count add_to_summary((*it)->sample.counts); return; } - size_t m = nr_modules; string current_module_name = (m == 0 ? "" : my_modules[m-1].get_name()); if (module != current_module_name) { // we have a module distinct from it's binary: --separate=lib // and this is the first symbol for this module if (m == 0) { - // mark end of enclosing binary - end = it; + // mark end of enclosing binary symbols if there have been any + // NOTE: it is possible for the binary's symbols to follow its + // module symbols + if (begin != (sym_iterator)0) + set_end(it); } else { // close out current module module_info & mod = my_modules[m-1]; @@ -738,10 +776,9 @@ void process_root_info::dump_processes() } binary_info * -binary_info::build_binary(string const & n, sym_iterator it) +binary_info::build_binary(string const & n) { name = n; - begin = it; lo = 0; hi = nr_classes-1; return this; @@ -755,7 +792,6 @@ void binary_info::output(ostream & out) output_summary(out); output_symbols(out); - for (size_t a = 0; a < nr_modules; ++a) my_modules[a].output(out); @@ -770,7 +806,7 @@ binary_root_info::add_binary(string cons // close out previous binary and module if (a > 0) binaries[a-1].close_binary(it); - return binaries[a].build_binary(n, it); + return binaries[a].build_binary(n); } @@ -783,7 +819,7 @@ void binary_root_info::output_binary_sym void binary_root_info::dump_binaries() { - cverb << vxml << "<!-- processes_dump:" << endl; + cverb << vxml << "<!-- binaries_dump:" << endl; for (size_t p = 0; p < nr_binaries; ++p) binaries[p].dump(); cverb << vxml << "end processes_dump -->" << endl; ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-17 19:02 Message: Logged In: YES user_id=1689878 Originator: NO I have been able to reproduce the problem and am working on a fix for it. ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 12:16 Message: Logged In: YES user_id=44495 Originator: YES I should also add that as you can probably see this was generated with --separate=lib ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 12:16 Message: Logged In: YES user_id=44495 Originator: YES I should also add that as you can probably see this was generated with --separate=lib ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 09:39 Message: Logged In: YES user_id=44495 Originator: YES Thank you for your quick response: "Are you saying that there is a <symbol> that is defined within the program, and not in a <module> and that it is being inserted in the list of symbols associated with the C library? If so could you give me a specific instance of this in your example?" Yes. This is a report of 'oprofiled'. e.g. Symbol with id=36 is is_sfile_anon as is defined in the program under analysis: <symboldata id="36" name="is_sfile_anon" file="/home/rob/o-hand/oprofile/oprofile-cvs-20070106/oprofile/daemon/opd_sfile.c" line="487" startingaddr="0804a9d0"/> This symbol is however included within the <module></module> block for the /lib/tls/i686/cmov/libc-2.5.so (line 161). Thank you for clarifying my other query. ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-12 00:46 Message: Logged In: YES user_id=1689878 Originator: NO I forgot to login before posting the previous response ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-11 22:37 Message: Logged In: NO Are you saying that there is a <symbol> that is defined within the program, and not in a <module> and that it is being inserted in the list of symbols associated with the C library? If so could you give me a specific instance of this in your example? In your "related note" I'm not sure what you mean by "associated with". A <symbol> is nested inside of <module> because it is the <module> that defines the <symbol>. The <module> is nested inside of <binary> because a program <binary> can link in (statically or dynamically) multiple libraries. It sounds like you are assigning a different meaning to <binary> than was intended. It is just a syntactic container for <module>s and can represent either a program or a library. The reason why a <binary> can be a library is in the case where there is no sampling data for the program binary, only for the libraries that it uses. A <symbol> is an instance of a symbol(since a symbol may be defined in multiple libraries) and contains its sample data. e.g. you could have lib1 and lib2 both define init() and each instance of "init" would have different sample data that must be separated. There is an XML schema file in doc/opreport.xsd that attempts to clarify these elements. If I've misunderstood your point please clarify for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 |
From: SourceForge.net <no...@so...> - 2007-01-18 13:24:46
|
Bugs item #1633312, was opened at 2007-01-11 15:46 Message generated for change (Comment added) made by robster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rob Bradford (robster) Assigned to: Nobody/Anonymous (nobody) Summary: XML output attributes symbols to incorrect module Initial Comment: The XML output subdivides each image (<binary></binary>) into modules (<module></module>) and includes the symbol counts for the symbol within that module. Unfortunately it seems to attribute the symbols of the program itself with one of the modules, e.g. the C library. In the attached XML file the symbols within oprofiled are are attributed to the C library. I believe that these should be included outside of a <module></module> block. On a related note why is the module (e.g. shared librarie)s, associated with the binary rather than the symbol. Surely a symbol is part of a shared library and thus used by the binary rather than the other way around. Regards, Rob ---------------------------------------------------------------------- >Comment By: Rob Bradford (robster) Date: 2007-01-18 13:24 Message: Logged In: YES user_id=44495 Originator: YES Could you please email me the patch or add it as a proper attachment. The sourceforge bug tracker is mangling the patch some what. ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-17 22:42 Message: Logged In: YES user_id=1689878 Originator: NO the following is a proposed patch to oprofile/libpp/xml_utils.cpp to fix the above problem. Rob, please let me know if this solves your problem or if you have any other issues before I submit the patch to the oprofile-developers mailing list. ====================================================================================== diff -paurN ../cvs_1_12/libpp/xml_utils.cpp ./libpp/xml_utils.cpp --- ../cvs_1_12/libpp/xml_utils.cpp 2006-11-17 17:47:29.000000000 -0600 +++ ./libpp/xml_utils.cpp 2007-01-17 16:30:50.486084080 -0600 @@ -60,7 +60,7 @@ size_t get_next_event_num_pclass(size_t } -void dump_it(string const & prefix, sym_iterator it, bool want_nl = true) +void dump_symbol(string const & prefix, sym_iterator it, bool want_nl = true) { if (it == symbols_end) cverb << vxml << prefix << "END"; @@ -71,6 +71,17 @@ void dump_it(string const & prefix, sym_ } +void dump_symbols(string const & prefix, sym_iterator b, sym_iterator e) +{ + if (b == (sym_iterator)0) + return; + + for (sym_iterator it = b; it != e; ++it) + dump_symbol(prefix, it, true); +} + + + void dump_classes() { cverb << vxml << "<!-- classes dump" << endl; @@ -425,6 +436,7 @@ public: void set_lo(size_t l) { lo = l; } void set_hi(size_t h) { hi = h; } count_array_t const & get_summary() { return summary; } + void set_begin(sym_iterator b); void set_end(sym_iterator e); void add_to_summary(count_array_t const & counts); void output(ostream & out); @@ -502,7 +514,7 @@ class binary_info : public module_info { public: binary_info() { nr_modules = 0; } void output(ostream & out); - binary_info * build_binary(string const & n, sym_iterator it); + binary_info * build_binary(string const & n); void add_module_symbol(string const & module, string const & app, sym_iterator it); void close_binary(sym_iterator it); @@ -547,6 +559,14 @@ void module_info::add_to_summary(count_a summary[pclass] += counts[pclass]; } + +void module_info::set_begin(sym_iterator b) +{ + if (begin == (sym_iterator)0) + begin = b; +} + + void module_info::set_end(sym_iterator e) { if (end == (sym_iterator)0) @@ -562,10 +582,9 @@ bool module_info::is_closed(string const void module_info::dump() { - cverb << vxml << "module:class(" << lo << "," << hi << ")="; + cverb << vxml << " module:class(" << lo << "," << hi << ")="; cverb << vxml << name << endl; - dump_it(" ", begin, false); - dump_it(" .. ", end-1); + dump_symbols(" ", begin, end); } @@ -588,6 +607,9 @@ void module_info::output_summary(ostream void module_info::output_symbols(ostream & out) { + if (begin == (sym_iterator)0) + return; + for (sym_iterator it = begin; it != end; ++it) xml_out->output_symbol(out, it, lo, hi); } @@ -595,15 +617,13 @@ void module_info::output_symbols(ostream void binary_info::close_binary(sym_iterator it) { + set_end(it); if (nr_modules > 0) { module_info & m = my_modules[nr_modules-1]; m.set_end(it); // propagate module summary to binary add_to_summary(m.get_summary()); - } else { - // close binary with no modules - set_end(it); } } @@ -611,6 +631,10 @@ void binary_info::close_binary(sym_itera void binary_info::dump() { cverb << vxml << "app_name=" << name << endl; + if (begin != (sym_iterator)0) { + dump_symbols(" ", begin, end); + } + for (size_t i = 0; i < nr_modules; ++i) my_modules[i].dump(); } @@ -620,20 +644,34 @@ void binary_info:: add_module_symbol(string const & module, string const & app, sym_iterator it) { + size_t m = nr_modules; + if (module == app) { + // set begin symbol for binary if not set + set_begin(it); + + if (m > 0) { + // close out current module + module_info & mod = my_modules[m-1]; + mod.set_end(it); + add_to_summary(mod.get_summary()); + } + // no module, so add symbol count to binary count add_to_summary((*it)->sample.counts); return; } - size_t m = nr_modules; string current_module_name = (m == 0 ? "" : my_modules[m-1].get_name()); if (module != current_module_name) { // we have a module distinct from it's binary: --separate=lib // and this is the first symbol for this module if (m == 0) { - // mark end of enclosing binary - end = it; + // mark end of enclosing binary symbols if there have been any + // NOTE: it is possible for the binary's symbols to follow its + // module symbols + if (begin != (sym_iterator)0) + set_end(it); } else { // close out current module module_info & mod = my_modules[m-1]; @@ -738,10 +776,9 @@ void process_root_info::dump_processes() } binary_info * -binary_info::build_binary(string const & n, sym_iterator it) +binary_info::build_binary(string const & n) { name = n; - begin = it; lo = 0; hi = nr_classes-1; return this; @@ -755,7 +792,6 @@ void binary_info::output(ostream & out) output_summary(out); output_symbols(out); - for (size_t a = 0; a < nr_modules; ++a) my_modules[a].output(out); @@ -770,7 +806,7 @@ binary_root_info::add_binary(string cons // close out previous binary and module if (a > 0) binaries[a-1].close_binary(it); - return binaries[a].build_binary(n, it); + return binaries[a].build_binary(n); } @@ -783,7 +819,7 @@ void binary_root_info::output_binary_sym void binary_root_info::dump_binaries() { - cverb << vxml << "<!-- processes_dump:" << endl; + cverb << vxml << "<!-- binaries_dump:" << endl; for (size_t p = 0; p < nr_binaries; ++p) binaries[p].dump(); cverb << vxml << "end processes_dump -->" << endl; ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-17 19:02 Message: Logged In: YES user_id=1689878 Originator: NO I have been able to reproduce the problem and am working on a fix for it. ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 12:16 Message: Logged In: YES user_id=44495 Originator: YES I should also add that as you can probably see this was generated with --separate=lib ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 12:16 Message: Logged In: YES user_id=44495 Originator: YES I should also add that as you can probably see this was generated with --separate=lib ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 09:39 Message: Logged In: YES user_id=44495 Originator: YES Thank you for your quick response: "Are you saying that there is a <symbol> that is defined within the program, and not in a <module> and that it is being inserted in the list of symbols associated with the C library? If so could you give me a specific instance of this in your example?" Yes. This is a report of 'oprofiled'. e.g. Symbol with id=36 is is_sfile_anon as is defined in the program under analysis: <symboldata id="36" name="is_sfile_anon" file="/home/rob/o-hand/oprofile/oprofile-cvs-20070106/oprofile/daemon/opd_sfile.c" line="487" startingaddr="0804a9d0"/> This symbol is however included within the <module></module> block for the /lib/tls/i686/cmov/libc-2.5.so (line 161). Thank you for clarifying my other query. ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-12 00:46 Message: Logged In: YES user_id=1689878 Originator: NO I forgot to login before posting the previous response ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-11 22:37 Message: Logged In: NO Are you saying that there is a <symbol> that is defined within the program, and not in a <module> and that it is being inserted in the list of symbols associated with the C library? If so could you give me a specific instance of this in your example? In your "related note" I'm not sure what you mean by "associated with". A <symbol> is nested inside of <module> because it is the <module> that defines the <symbol>. The <module> is nested inside of <binary> because a program <binary> can link in (statically or dynamically) multiple libraries. It sounds like you are assigning a different meaning to <binary> than was intended. It is just a syntactic container for <module>s and can represent either a program or a library. The reason why a <binary> can be a library is in the case where there is no sampling data for the program binary, only for the libraries that it uses. A <symbol> is an instance of a symbol(since a symbol may be defined in multiple libraries) and contains its sample data. e.g. you could have lib1 and lib2 both define init() and each instance of "init" would have different sample data that must be separated. There is an XML schema file in doc/opreport.xsd that attempts to clarify these elements. If I've misunderstood your point please clarify for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 |
From: SourceForge.net <no...@so...> - 2007-01-30 19:01:09
|
Bugs item #1633312, was opened at 2007-01-11 15:46 Message generated for change (Comment added) made by dcnomura You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rob Bradford (robster) Assigned to: Nobody/Anonymous (nobody) Summary: XML output attributes symbols to incorrect module Initial Comment: The XML output subdivides each image (<binary></binary>) into modules (<module></module>) and includes the symbol counts for the symbol within that module. Unfortunately it seems to attribute the symbols of the program itself with one of the modules, e.g. the C library. In the attached XML file the symbols within oprofiled are are attributed to the C library. I believe that these should be included outside of a <module></module> block. On a related note why is the module (e.g. shared librarie)s, associated with the binary rather than the symbol. Surely a symbol is part of a shared library and thus used by the binary rather than the other way around. Regards, Rob ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-30 19:01 Message: Logged In: YES user_id=1689878 Originator: NO The patch has been commited to the Oprofile CVS source: http://marc.theaimsgroup.com/?l=oprofile-commits&m=116989566131119&w=2 This bug can be closed. It is not clear to me how to do this. ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-18 13:24 Message: Logged In: YES user_id=44495 Originator: YES Could you please email me the patch or add it as a proper attachment. The sourceforge bug tracker is mangling the patch some what. ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-17 22:42 Message: Logged In: YES user_id=1689878 Originator: NO the following is a proposed patch to oprofile/libpp/xml_utils.cpp to fix the above problem. Rob, please let me know if this solves your problem or if you have any other issues before I submit the patch to the oprofile-developers mailing list. ====================================================================================== diff -paurN ../cvs_1_12/libpp/xml_utils.cpp ./libpp/xml_utils.cpp --- ../cvs_1_12/libpp/xml_utils.cpp 2006-11-17 17:47:29.000000000 -0600 +++ ./libpp/xml_utils.cpp 2007-01-17 16:30:50.486084080 -0600 @@ -60,7 +60,7 @@ size_t get_next_event_num_pclass(size_t } -void dump_it(string const & prefix, sym_iterator it, bool want_nl = true) +void dump_symbol(string const & prefix, sym_iterator it, bool want_nl = true) { if (it == symbols_end) cverb << vxml << prefix << "END"; @@ -71,6 +71,17 @@ void dump_it(string const & prefix, sym_ } +void dump_symbols(string const & prefix, sym_iterator b, sym_iterator e) +{ + if (b == (sym_iterator)0) + return; + + for (sym_iterator it = b; it != e; ++it) + dump_symbol(prefix, it, true); +} + + + void dump_classes() { cverb << vxml << "<!-- classes dump" << endl; @@ -425,6 +436,7 @@ public: void set_lo(size_t l) { lo = l; } void set_hi(size_t h) { hi = h; } count_array_t const & get_summary() { return summary; } + void set_begin(sym_iterator b); void set_end(sym_iterator e); void add_to_summary(count_array_t const & counts); void output(ostream & out); @@ -502,7 +514,7 @@ class binary_info : public module_info { public: binary_info() { nr_modules = 0; } void output(ostream & out); - binary_info * build_binary(string const & n, sym_iterator it); + binary_info * build_binary(string const & n); void add_module_symbol(string const & module, string const & app, sym_iterator it); void close_binary(sym_iterator it); @@ -547,6 +559,14 @@ void module_info::add_to_summary(count_a summary[pclass] += counts[pclass]; } + +void module_info::set_begin(sym_iterator b) +{ + if (begin == (sym_iterator)0) + begin = b; +} + + void module_info::set_end(sym_iterator e) { if (end == (sym_iterator)0) @@ -562,10 +582,9 @@ bool module_info::is_closed(string const void module_info::dump() { - cverb << vxml << "module:class(" << lo << "," << hi << ")="; + cverb << vxml << " module:class(" << lo << "," << hi << ")="; cverb << vxml << name << endl; - dump_it(" ", begin, false); - dump_it(" .. ", end-1); + dump_symbols(" ", begin, end); } @@ -588,6 +607,9 @@ void module_info::output_summary(ostream void module_info::output_symbols(ostream & out) { + if (begin == (sym_iterator)0) + return; + for (sym_iterator it = begin; it != end; ++it) xml_out->output_symbol(out, it, lo, hi); } @@ -595,15 +617,13 @@ void module_info::output_symbols(ostream void binary_info::close_binary(sym_iterator it) { + set_end(it); if (nr_modules > 0) { module_info & m = my_modules[nr_modules-1]; m.set_end(it); // propagate module summary to binary add_to_summary(m.get_summary()); - } else { - // close binary with no modules - set_end(it); } } @@ -611,6 +631,10 @@ void binary_info::close_binary(sym_itera void binary_info::dump() { cverb << vxml << "app_name=" << name << endl; + if (begin != (sym_iterator)0) { + dump_symbols(" ", begin, end); + } + for (size_t i = 0; i < nr_modules; ++i) my_modules[i].dump(); } @@ -620,20 +644,34 @@ void binary_info:: add_module_symbol(string const & module, string const & app, sym_iterator it) { + size_t m = nr_modules; + if (module == app) { + // set begin symbol for binary if not set + set_begin(it); + + if (m > 0) { + // close out current module + module_info & mod = my_modules[m-1]; + mod.set_end(it); + add_to_summary(mod.get_summary()); + } + // no module, so add symbol count to binary count add_to_summary((*it)->sample.counts); return; } - size_t m = nr_modules; string current_module_name = (m == 0 ? "" : my_modules[m-1].get_name()); if (module != current_module_name) { // we have a module distinct from it's binary: --separate=lib // and this is the first symbol for this module if (m == 0) { - // mark end of enclosing binary - end = it; + // mark end of enclosing binary symbols if there have been any + // NOTE: it is possible for the binary's symbols to follow its + // module symbols + if (begin != (sym_iterator)0) + set_end(it); } else { // close out current module module_info & mod = my_modules[m-1]; @@ -738,10 +776,9 @@ void process_root_info::dump_processes() } binary_info * -binary_info::build_binary(string const & n, sym_iterator it) +binary_info::build_binary(string const & n) { name = n; - begin = it; lo = 0; hi = nr_classes-1; return this; @@ -755,7 +792,6 @@ void binary_info::output(ostream & out) output_summary(out); output_symbols(out); - for (size_t a = 0; a < nr_modules; ++a) my_modules[a].output(out); @@ -770,7 +806,7 @@ binary_root_info::add_binary(string cons // close out previous binary and module if (a > 0) binaries[a-1].close_binary(it); - return binaries[a].build_binary(n, it); + return binaries[a].build_binary(n); } @@ -783,7 +819,7 @@ void binary_root_info::output_binary_sym void binary_root_info::dump_binaries() { - cverb << vxml << "<!-- processes_dump:" << endl; + cverb << vxml << "<!-- binaries_dump:" << endl; for (size_t p = 0; p < nr_binaries; ++p) binaries[p].dump(); cverb << vxml << "end processes_dump -->" << endl; ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-17 19:02 Message: Logged In: YES user_id=1689878 Originator: NO I have been able to reproduce the problem and am working on a fix for it. ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 12:16 Message: Logged In: YES user_id=44495 Originator: YES I should also add that as you can probably see this was generated with --separate=lib ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 12:16 Message: Logged In: YES user_id=44495 Originator: YES I should also add that as you can probably see this was generated with --separate=lib ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 09:39 Message: Logged In: YES user_id=44495 Originator: YES Thank you for your quick response: "Are you saying that there is a <symbol> that is defined within the program, and not in a <module> and that it is being inserted in the list of symbols associated with the C library? If so could you give me a specific instance of this in your example?" Yes. This is a report of 'oprofiled'. e.g. Symbol with id=36 is is_sfile_anon as is defined in the program under analysis: <symboldata id="36" name="is_sfile_anon" file="/home/rob/o-hand/oprofile/oprofile-cvs-20070106/oprofile/daemon/opd_sfile.c" line="487" startingaddr="0804a9d0"/> This symbol is however included within the <module></module> block for the /lib/tls/i686/cmov/libc-2.5.so (line 161). Thank you for clarifying my other query. ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-12 00:46 Message: Logged In: YES user_id=1689878 Originator: NO I forgot to login before posting the previous response ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-11 22:37 Message: Logged In: NO Are you saying that there is a <symbol> that is defined within the program, and not in a <module> and that it is being inserted in the list of symbols associated with the C library? If so could you give me a specific instance of this in your example? In your "related note" I'm not sure what you mean by "associated with". A <symbol> is nested inside of <module> because it is the <module> that defines the <symbol>. The <module> is nested inside of <binary> because a program <binary> can link in (statically or dynamically) multiple libraries. It sounds like you are assigning a different meaning to <binary> than was intended. It is just a syntactic container for <module>s and can represent either a program or a library. The reason why a <binary> can be a library is in the case where there is no sampling data for the program binary, only for the libraries that it uses. A <symbol> is an instance of a symbol(since a symbol may be defined in multiple libraries) and contains its sample data. e.g. you could have lib1 and lib2 both define init() and each instance of "init" would have different sample data that must be separated. There is an XML schema file in doc/opreport.xsd that attempts to clarify these elements. If I've misunderstood your point please clarify for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 |
From: SourceForge.net <no...@so...> - 2007-05-20 18:17:16
|
Bugs item #1633312, was opened at 2007-01-11 15:46 Message generated for change (Comment added) made by movement You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Rob Bradford (robster) Assigned to: Nobody/Anonymous (nobody) Summary: XML output attributes symbols to incorrect module Initial Comment: The XML output subdivides each image (<binary></binary>) into modules (<module></module>) and includes the symbol counts for the symbol within that module. Unfortunately it seems to attribute the symbols of the program itself with one of the modules, e.g. the C library. In the attached XML file the symbols within oprofiled are are attributed to the C library. I believe that these should be included outside of a <module></module> block. On a related note why is the module (e.g. shared librarie)s, associated with the binary rather than the symbol. Surely a symbol is part of a shared library and thus used by the binary rather than the other way around. Regards, Rob ---------------------------------------------------------------------- >Comment By: John Levon (movement) Date: 2007-05-20 18:17 Message: Logged In: YES user_id=53034 Originator: NO Fixed. Stays open until release of 0.9.3 ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-30 19:01 Message: Logged In: YES user_id=1689878 Originator: NO The patch has been commited to the Oprofile CVS source: http://marc.theaimsgroup.com/?l=oprofile-commits&m=116989566131119&w=2 This bug can be closed. It is not clear to me how to do this. ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-18 13:24 Message: Logged In: YES user_id=44495 Originator: YES Could you please email me the patch or add it as a proper attachment. The sourceforge bug tracker is mangling the patch some what. ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-17 22:42 Message: Logged In: YES user_id=1689878 Originator: NO the following is a proposed patch to oprofile/libpp/xml_utils.cpp to fix the above problem. Rob, please let me know if this solves your problem or if you have any other issues before I submit the patch to the oprofile-developers mailing list. ====================================================================================== diff -paurN ../cvs_1_12/libpp/xml_utils.cpp ./libpp/xml_utils.cpp --- ../cvs_1_12/libpp/xml_utils.cpp 2006-11-17 17:47:29.000000000 -0600 +++ ./libpp/xml_utils.cpp 2007-01-17 16:30:50.486084080 -0600 @@ -60,7 +60,7 @@ size_t get_next_event_num_pclass(size_t } -void dump_it(string const & prefix, sym_iterator it, bool want_nl = true) +void dump_symbol(string const & prefix, sym_iterator it, bool want_nl = true) { if (it == symbols_end) cverb << vxml << prefix << "END"; @@ -71,6 +71,17 @@ void dump_it(string const & prefix, sym_ } +void dump_symbols(string const & prefix, sym_iterator b, sym_iterator e) +{ + if (b == (sym_iterator)0) + return; + + for (sym_iterator it = b; it != e; ++it) + dump_symbol(prefix, it, true); +} + + + void dump_classes() { cverb << vxml << "<!-- classes dump" << endl; @@ -425,6 +436,7 @@ public: void set_lo(size_t l) { lo = l; } void set_hi(size_t h) { hi = h; } count_array_t const & get_summary() { return summary; } + void set_begin(sym_iterator b); void set_end(sym_iterator e); void add_to_summary(count_array_t const & counts); void output(ostream & out); @@ -502,7 +514,7 @@ class binary_info : public module_info { public: binary_info() { nr_modules = 0; } void output(ostream & out); - binary_info * build_binary(string const & n, sym_iterator it); + binary_info * build_binary(string const & n); void add_module_symbol(string const & module, string const & app, sym_iterator it); void close_binary(sym_iterator it); @@ -547,6 +559,14 @@ void module_info::add_to_summary(count_a summary[pclass] += counts[pclass]; } + +void module_info::set_begin(sym_iterator b) +{ + if (begin == (sym_iterator)0) + begin = b; +} + + void module_info::set_end(sym_iterator e) { if (end == (sym_iterator)0) @@ -562,10 +582,9 @@ bool module_info::is_closed(string const void module_info::dump() { - cverb << vxml << "module:class(" << lo << "," << hi << ")="; + cverb << vxml << " module:class(" << lo << "," << hi << ")="; cverb << vxml << name << endl; - dump_it(" ", begin, false); - dump_it(" .. ", end-1); + dump_symbols(" ", begin, end); } @@ -588,6 +607,9 @@ void module_info::output_summary(ostream void module_info::output_symbols(ostream & out) { + if (begin == (sym_iterator)0) + return; + for (sym_iterator it = begin; it != end; ++it) xml_out->output_symbol(out, it, lo, hi); } @@ -595,15 +617,13 @@ void module_info::output_symbols(ostream void binary_info::close_binary(sym_iterator it) { + set_end(it); if (nr_modules > 0) { module_info & m = my_modules[nr_modules-1]; m.set_end(it); // propagate module summary to binary add_to_summary(m.get_summary()); - } else { - // close binary with no modules - set_end(it); } } @@ -611,6 +631,10 @@ void binary_info::close_binary(sym_itera void binary_info::dump() { cverb << vxml << "app_name=" << name << endl; + if (begin != (sym_iterator)0) { + dump_symbols(" ", begin, end); + } + for (size_t i = 0; i < nr_modules; ++i) my_modules[i].dump(); } @@ -620,20 +644,34 @@ void binary_info:: add_module_symbol(string const & module, string const & app, sym_iterator it) { + size_t m = nr_modules; + if (module == app) { + // set begin symbol for binary if not set + set_begin(it); + + if (m > 0) { + // close out current module + module_info & mod = my_modules[m-1]; + mod.set_end(it); + add_to_summary(mod.get_summary()); + } + // no module, so add symbol count to binary count add_to_summary((*it)->sample.counts); return; } - size_t m = nr_modules; string current_module_name = (m == 0 ? "" : my_modules[m-1].get_name()); if (module != current_module_name) { // we have a module distinct from it's binary: --separate=lib // and this is the first symbol for this module if (m == 0) { - // mark end of enclosing binary - end = it; + // mark end of enclosing binary symbols if there have been any + // NOTE: it is possible for the binary's symbols to follow its + // module symbols + if (begin != (sym_iterator)0) + set_end(it); } else { // close out current module module_info & mod = my_modules[m-1]; @@ -738,10 +776,9 @@ void process_root_info::dump_processes() } binary_info * -binary_info::build_binary(string const & n, sym_iterator it) +binary_info::build_binary(string const & n) { name = n; - begin = it; lo = 0; hi = nr_classes-1; return this; @@ -755,7 +792,6 @@ void binary_info::output(ostream & out) output_summary(out); output_symbols(out); - for (size_t a = 0; a < nr_modules; ++a) my_modules[a].output(out); @@ -770,7 +806,7 @@ binary_root_info::add_binary(string cons // close out previous binary and module if (a > 0) binaries[a-1].close_binary(it); - return binaries[a].build_binary(n, it); + return binaries[a].build_binary(n); } @@ -783,7 +819,7 @@ void binary_root_info::output_binary_sym void binary_root_info::dump_binaries() { - cverb << vxml << "<!-- processes_dump:" << endl; + cverb << vxml << "<!-- binaries_dump:" << endl; for (size_t p = 0; p < nr_binaries; ++p) binaries[p].dump(); cverb << vxml << "end processes_dump -->" << endl; ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-17 19:02 Message: Logged In: YES user_id=1689878 Originator: NO I have been able to reproduce the problem and am working on a fix for it. ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 12:16 Message: Logged In: YES user_id=44495 Originator: YES I should also add that as you can probably see this was generated with --separate=lib ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 12:16 Message: Logged In: YES user_id=44495 Originator: YES I should also add that as you can probably see this was generated with --separate=lib ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 09:39 Message: Logged In: YES user_id=44495 Originator: YES Thank you for your quick response: "Are you saying that there is a <symbol> that is defined within the program, and not in a <module> and that it is being inserted in the list of symbols associated with the C library? If so could you give me a specific instance of this in your example?" Yes. This is a report of 'oprofiled'. e.g. Symbol with id=36 is is_sfile_anon as is defined in the program under analysis: <symboldata id="36" name="is_sfile_anon" file="/home/rob/o-hand/oprofile/oprofile-cvs-20070106/oprofile/daemon/opd_sfile.c" line="487" startingaddr="0804a9d0"/> This symbol is however included within the <module></module> block for the /lib/tls/i686/cmov/libc-2.5.so (line 161). Thank you for clarifying my other query. ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-12 00:46 Message: Logged In: YES user_id=1689878 Originator: NO I forgot to login before posting the previous response ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-11 22:37 Message: Logged In: NO Are you saying that there is a <symbol> that is defined within the program, and not in a <module> and that it is being inserted in the list of symbols associated with the C library? If so could you give me a specific instance of this in your example? In your "related note" I'm not sure what you mean by "associated with". A <symbol> is nested inside of <module> because it is the <module> that defines the <symbol>. The <module> is nested inside of <binary> because a program <binary> can link in (statically or dynamically) multiple libraries. It sounds like you are assigning a different meaning to <binary> than was intended. It is just a syntactic container for <module>s and can represent either a program or a library. The reason why a <binary> can be a library is in the case where there is no sampling data for the program binary, only for the libraries that it uses. A <symbol> is an instance of a symbol(since a symbol may be defined in multiple libraries) and contains its sample data. e.g. you could have lib1 and lib2 both define init() and each instance of "init" would have different sample data that must be separated. There is an XML schema file in doc/opreport.xsd that attempts to clarify these elements. If I've misunderstood your point please clarify for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 |
From: SourceForge.net <no...@so...> - 2007-05-20 18:22:11
|
Bugs item #1633312, was opened at 2007-01-11 15:46 Message generated for change (Comment added) made by movement You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Rob Bradford (robster) Assigned to: Nobody/Anonymous (nobody) Summary: XML output attributes symbols to incorrect module Initial Comment: The XML output subdivides each image (<binary></binary>) into modules (<module></module>) and includes the symbol counts for the symbol within that module. Unfortunately it seems to attribute the symbols of the program itself with one of the modules, e.g. the C library. In the attached XML file the symbols within oprofiled are are attributed to the C library. I believe that these should be included outside of a <module></module> block. On a related note why is the module (e.g. shared librarie)s, associated with the binary rather than the symbol. Surely a symbol is part of a shared library and thus used by the binary rather than the other way around. Regards, Rob ---------------------------------------------------------------------- >Comment By: John Levon (movement) Date: 2007-05-20 18:22 Message: Logged In: YES user_id=53034 Originator: NO Ooops, we can close this now since it's not in 0.9.2 ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2007-05-20 18:17 Message: Logged In: YES user_id=53034 Originator: NO Fixed. Stays open until release of 0.9.3 ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-30 19:01 Message: Logged In: YES user_id=1689878 Originator: NO The patch has been commited to the Oprofile CVS source: http://marc.theaimsgroup.com/?l=oprofile-commits&m=116989566131119&w=2 This bug can be closed. It is not clear to me how to do this. ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-18 13:24 Message: Logged In: YES user_id=44495 Originator: YES Could you please email me the patch or add it as a proper attachment. The sourceforge bug tracker is mangling the patch some what. ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-17 22:42 Message: Logged In: YES user_id=1689878 Originator: NO the following is a proposed patch to oprofile/libpp/xml_utils.cpp to fix the above problem. Rob, please let me know if this solves your problem or if you have any other issues before I submit the patch to the oprofile-developers mailing list. ====================================================================================== diff -paurN ../cvs_1_12/libpp/xml_utils.cpp ./libpp/xml_utils.cpp --- ../cvs_1_12/libpp/xml_utils.cpp 2006-11-17 17:47:29.000000000 -0600 +++ ./libpp/xml_utils.cpp 2007-01-17 16:30:50.486084080 -0600 @@ -60,7 +60,7 @@ size_t get_next_event_num_pclass(size_t } -void dump_it(string const & prefix, sym_iterator it, bool want_nl = true) +void dump_symbol(string const & prefix, sym_iterator it, bool want_nl = true) { if (it == symbols_end) cverb << vxml << prefix << "END"; @@ -71,6 +71,17 @@ void dump_it(string const & prefix, sym_ } +void dump_symbols(string const & prefix, sym_iterator b, sym_iterator e) +{ + if (b == (sym_iterator)0) + return; + + for (sym_iterator it = b; it != e; ++it) + dump_symbol(prefix, it, true); +} + + + void dump_classes() { cverb << vxml << "<!-- classes dump" << endl; @@ -425,6 +436,7 @@ public: void set_lo(size_t l) { lo = l; } void set_hi(size_t h) { hi = h; } count_array_t const & get_summary() { return summary; } + void set_begin(sym_iterator b); void set_end(sym_iterator e); void add_to_summary(count_array_t const & counts); void output(ostream & out); @@ -502,7 +514,7 @@ class binary_info : public module_info { public: binary_info() { nr_modules = 0; } void output(ostream & out); - binary_info * build_binary(string const & n, sym_iterator it); + binary_info * build_binary(string const & n); void add_module_symbol(string const & module, string const & app, sym_iterator it); void close_binary(sym_iterator it); @@ -547,6 +559,14 @@ void module_info::add_to_summary(count_a summary[pclass] += counts[pclass]; } + +void module_info::set_begin(sym_iterator b) +{ + if (begin == (sym_iterator)0) + begin = b; +} + + void module_info::set_end(sym_iterator e) { if (end == (sym_iterator)0) @@ -562,10 +582,9 @@ bool module_info::is_closed(string const void module_info::dump() { - cverb << vxml << "module:class(" << lo << "," << hi << ")="; + cverb << vxml << " module:class(" << lo << "," << hi << ")="; cverb << vxml << name << endl; - dump_it(" ", begin, false); - dump_it(" .. ", end-1); + dump_symbols(" ", begin, end); } @@ -588,6 +607,9 @@ void module_info::output_summary(ostream void module_info::output_symbols(ostream & out) { + if (begin == (sym_iterator)0) + return; + for (sym_iterator it = begin; it != end; ++it) xml_out->output_symbol(out, it, lo, hi); } @@ -595,15 +617,13 @@ void module_info::output_symbols(ostream void binary_info::close_binary(sym_iterator it) { + set_end(it); if (nr_modules > 0) { module_info & m = my_modules[nr_modules-1]; m.set_end(it); // propagate module summary to binary add_to_summary(m.get_summary()); - } else { - // close binary with no modules - set_end(it); } } @@ -611,6 +631,10 @@ void binary_info::close_binary(sym_itera void binary_info::dump() { cverb << vxml << "app_name=" << name << endl; + if (begin != (sym_iterator)0) { + dump_symbols(" ", begin, end); + } + for (size_t i = 0; i < nr_modules; ++i) my_modules[i].dump(); } @@ -620,20 +644,34 @@ void binary_info:: add_module_symbol(string const & module, string const & app, sym_iterator it) { + size_t m = nr_modules; + if (module == app) { + // set begin symbol for binary if not set + set_begin(it); + + if (m > 0) { + // close out current module + module_info & mod = my_modules[m-1]; + mod.set_end(it); + add_to_summary(mod.get_summary()); + } + // no module, so add symbol count to binary count add_to_summary((*it)->sample.counts); return; } - size_t m = nr_modules; string current_module_name = (m == 0 ? "" : my_modules[m-1].get_name()); if (module != current_module_name) { // we have a module distinct from it's binary: --separate=lib // and this is the first symbol for this module if (m == 0) { - // mark end of enclosing binary - end = it; + // mark end of enclosing binary symbols if there have been any + // NOTE: it is possible for the binary's symbols to follow its + // module symbols + if (begin != (sym_iterator)0) + set_end(it); } else { // close out current module module_info & mod = my_modules[m-1]; @@ -738,10 +776,9 @@ void process_root_info::dump_processes() } binary_info * -binary_info::build_binary(string const & n, sym_iterator it) +binary_info::build_binary(string const & n) { name = n; - begin = it; lo = 0; hi = nr_classes-1; return this; @@ -755,7 +792,6 @@ void binary_info::output(ostream & out) output_summary(out); output_symbols(out); - for (size_t a = 0; a < nr_modules; ++a) my_modules[a].output(out); @@ -770,7 +806,7 @@ binary_root_info::add_binary(string cons // close out previous binary and module if (a > 0) binaries[a-1].close_binary(it); - return binaries[a].build_binary(n, it); + return binaries[a].build_binary(n); } @@ -783,7 +819,7 @@ void binary_root_info::output_binary_sym void binary_root_info::dump_binaries() { - cverb << vxml << "<!-- processes_dump:" << endl; + cverb << vxml << "<!-- binaries_dump:" << endl; for (size_t p = 0; p < nr_binaries; ++p) binaries[p].dump(); cverb << vxml << "end processes_dump -->" << endl; ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-17 19:02 Message: Logged In: YES user_id=1689878 Originator: NO I have been able to reproduce the problem and am working on a fix for it. ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 12:16 Message: Logged In: YES user_id=44495 Originator: YES I should also add that as you can probably see this was generated with --separate=lib ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 12:16 Message: Logged In: YES user_id=44495 Originator: YES I should also add that as you can probably see this was generated with --separate=lib ---------------------------------------------------------------------- Comment By: Rob Bradford (robster) Date: 2007-01-12 09:39 Message: Logged In: YES user_id=44495 Originator: YES Thank you for your quick response: "Are you saying that there is a <symbol> that is defined within the program, and not in a <module> and that it is being inserted in the list of symbols associated with the C library? If so could you give me a specific instance of this in your example?" Yes. This is a report of 'oprofiled'. e.g. Symbol with id=36 is is_sfile_anon as is defined in the program under analysis: <symboldata id="36" name="is_sfile_anon" file="/home/rob/o-hand/oprofile/oprofile-cvs-20070106/oprofile/daemon/opd_sfile.c" line="487" startingaddr="0804a9d0"/> This symbol is however included within the <module></module> block for the /lib/tls/i686/cmov/libc-2.5.so (line 161). Thank you for clarifying my other query. ---------------------------------------------------------------------- Comment By: Dave Nomura (dcnomura) Date: 2007-01-12 00:46 Message: Logged In: YES user_id=1689878 Originator: NO I forgot to login before posting the previous response ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-11 22:37 Message: Logged In: NO Are you saying that there is a <symbol> that is defined within the program, and not in a <module> and that it is being inserted in the list of symbols associated with the C library? If so could you give me a specific instance of this in your example? In your "related note" I'm not sure what you mean by "associated with". A <symbol> is nested inside of <module> because it is the <module> that defines the <symbol>. The <module> is nested inside of <binary> because a program <binary> can link in (statically or dynamically) multiple libraries. It sounds like you are assigning a different meaning to <binary> than was intended. It is just a syntactic container for <module>s and can represent either a program or a library. The reason why a <binary> can be a library is in the case where there is no sampling data for the program binary, only for the libraries that it uses. A <symbol> is an instance of a symbol(since a symbol may be defined in multiple libraries) and contains its sample data. e.g. you could have lib1 and lib2 both define init() and each instance of "init" would have different sample data that must be separated. There is an XML schema file in doc/opreport.xsd that attempts to clarify these elements. If I've misunderstood your point please clarify for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1633312&group_id=16191 |