From: Maynard P. J. <may...@us...> - 2005-04-08 23:02:38
|
Hi, We've done some additional testing of the patch I sent earlier this week = that handles the removal of the "dotted" symbols from elf64. We tested = opannotate on PPC64/RHEL 4, both with and without the patch. Without = the patch, opannotate was not producing annotated source for 64-bit = programs. With the patch applied, we were seeing a segmentation fault = in BFD code, elf_find_function, called by _bfd_elf_find_nearest_line, = called by op_bfd::get_linenr. Investigation of this problem is = indicating a probable bug in BFD, so our in-house BFD person is working = on that.=20 A workaround is to check the symbol prior to calling = _bfd_elf_find_nearest_line; if it's a "no-name" section symbol, then we = skip the call to _bfd_elf_find_nearest_line. This should be a valid = workaround since there's no possibility of finding a line number in the = source for a section symbol anyway. This fix is working fine in our = testing on RHEL 4, so I've opened a bug to get the fix pushed into RHEL = 4. =20 However, as before, I'm sure the Red Hat folks will want the patch = accepted upstream before they accept it. The problem is that opannotate = is broken in CVS right now. I get a segmentation fault trying to use it = as is on either Intel or PPC64 platforms. The seg fault is coming from = line 682 in op_bfd::has_debug_info(). In the initialization of the = for-loop, 'ibfd', may be null. If I put a check for null prior to that = and return debug_info.reset(false), I get all the way through the = program without apparent errors, but no annotated source is created. I see that the changes involving debug info were just committed into CVS = this week, so maybe I'm grabbing something out of CVS that's not quite = completely baked yet. Is there a snapshot or some CVS branch I can use = to test my patch so I can submit it to the mailing list? Thanks, and sorry for the long-winded note. P.S. By the way, I also tested opstack and opgprof on RHEL 4. opstack = appears to work fine, with or without the "dot" symbol patch applied. = opgrof is not functioning properly, as it turns out, because gprof = itself is broken. I opened a bug for that problem to have our in-house = binutils person fix that. This is a problem only for 64-bit programs on = PPC64 (as far as I am aware) -- no doubt, another casualty of the = removal of the "dot" symbols.=20 Regards, Maynard Johnson IBM Linux Technology Center |
From: Philippe E. <ph...@wa...> - 2005-04-09 03:30:04
|
On Fri, 08 Apr 2005 at 18:03 +0000, Maynard P. Johnson wrote: > However, as before, I'm sure the Red Hat folks will want the patch accepted upstream before they accept it. The problem is that opannotate is broken in CVS right now. I get a segmentation fault trying to use it as is on either Intel or PPC64 platforms. The seg fault is coming from line 682 in op_bfd::has_debug_info(). In the initialization of the for-loop, 'ibfd', may be null. If I put a check for null prior to that and return debug_info.reset(false), I get all the way through the program without apparent errors, but no annotated source is created. I fixed it in the way you suggested. > I see that the changes involving debug info were just committed into CVS this week, so maybe I'm grabbing something out of CVS that's not quite completely baked yet. Is there a snapshot or some CVS branch I can use to test my patch so I can submit it to the mailing list? Try with the current CVS, public cvs lag by five hours actually, if you don't get my last checkin apply this patch to your copy : Phil. ? utils/op_help Index: ChangeLog =================================================================== RCS file: /cvsroot/oprofile/oprofile/ChangeLog,v retrieving revision 1.1566 diff -u -p -r1.1566 ChangeLog --- ChangeLog 7 Apr 2005 02:59:32 -0000 1.1566 +++ ChangeLog 9 Apr 2005 03:19:07 -0000 @@ -1,3 +1,11 @@ +2005-04-09 Philippe Elie <ph...@wa...> + + * libutil++/op_bfd.h: + * libutil++/op_bfd.cpp: fix a segfault if a binary file can't be + accessed (opreport -gl; opannotate) problem and solution pointed + by Maynard P. Johnson <may...@us...>. All public interface + of op_bfd object must check for a NULL ibfd before using it. + 2005-04-07 John Levon <le...@mo...> * libutil/tests/Makefile.am: Index: libutil++/op_bfd.cpp =================================================================== RCS file: /cvsroot/oprofile/oprofile/libutil++/op_bfd.cpp,v retrieving revision 1.62 diff -u -p -r1.62 op_bfd.cpp --- libutil++/op_bfd.cpp 6 Apr 2005 23:24:48 -0000 1.62 +++ libutil++/op_bfd.cpp 9 Apr 2005 03:19:10 -0000 @@ -677,6 +677,9 @@ bool op_bfd::has_debug_info() const if (debug_info.cached()) return debug_info.get(); + if (!ibfd) + return debug_info.reset(true); + asection const * sect; for (sect = ibfd->sections; sect; sect = sect->next) { Index: libutil++/op_bfd.h =================================================================== RCS file: /cvsroot/oprofile/oprofile/libutil++/op_bfd.h,v retrieving revision 1.35 diff -u -p -r1.35 op_bfd.h --- libutil++/op_bfd.h 6 Apr 2005 21:07:07 -0000 1.35 +++ libutil++/op_bfd.h 9 Apr 2005 03:19:11 -0000 @@ -183,7 +183,7 @@ private: /// file size in bytes off_t file_size; - // the bfd object. + // the bfd object, NULL if the binary file can't be accessed. bfd * ibfd; // The following member variables: debug_filename and dbfd are |
From: Maynard P. J. <may...@us...> - 2005-04-11 12:26:27
|
Maynard Johnson IBM Linux Technology Center ----- Original Message ----- From: "Philippe Elie" <ph...@wa...> To: "Maynard P. Johnson" <may...@us...> Cc: <opr...@li...> Sent: Friday, April 08, 2005 10:34 PM Subject: Re: opannotate broken in CVS > On Fri, 08 Apr 2005 at 18:03 +0000, Maynard P. Johnson wrote: > The seg fault is coming from line 682 in op_bfd::has_debug_info(). In the initialization of the for-loop, 'ibfd', may be null. If I put a check for null prior to that and return debug_info.reset(false), I get all the way through the program without apparent errors, but no annotated source is created. > > I fixed it in the way you suggested. > OK, the seg fault is fixed in CVS now. Thanks. However, I'm still not getting any annotated source created. Can you help with that problem, too, Philippe? Regards, -Maynard > Try with the current CVS, public cvs lag by five hours actually, if you don't > get my last checkin apply this patch to your copy : > > Phil. > > ? utils/op_help > Index: ChangeLog > =================================================================== > RCS file: /cvsroot/oprofile/oprofile/ChangeLog,v > retrieving revision 1.1566 > diff -u -p -r1.1566 ChangeLog > --- ChangeLog 7 Apr 2005 02:59:32 -0000 1.1566 > +++ ChangeLog 9 Apr 2005 03:19:07 -0000 > @@ -1,3 +1,11 @@ > +2005-04-09 Philippe Elie <ph...@wa...> > + > + * libutil++/op_bfd.h: > + * libutil++/op_bfd.cpp: fix a segfault if a binary file can't be > + accessed (opreport -gl; opannotate) problem and solution pointed > + by Maynard P. Johnson <may...@us...>. All public interface > + of op_bfd object must check for a NULL ibfd before using it. > + > 2005-04-07 John Levon <le...@mo...> > > * libutil/tests/Makefile.am: > Index: libutil++/op_bfd.cpp > =================================================================== > RCS file: /cvsroot/oprofile/oprofile/libutil++/op_bfd.cpp,v > retrieving revision 1.62 > diff -u -p -r1.62 op_bfd.cpp > --- libutil++/op_bfd.cpp 6 Apr 2005 23:24:48 -0000 1.62 > +++ libutil++/op_bfd.cpp 9 Apr 2005 03:19:10 -0000 > @@ -677,6 +677,9 @@ bool op_bfd::has_debug_info() const > if (debug_info.cached()) > return debug_info.get(); > > + if (!ibfd) > + return debug_info.reset(true); > + > asection const * sect; > > for (sect = ibfd->sections; sect; sect = sect->next) { > Index: libutil++/op_bfd.h > =================================================================== > RCS file: /cvsroot/oprofile/oprofile/libutil++/op_bfd.h,v > retrieving revision 1.35 > diff -u -p -r1.35 op_bfd.h > --- libutil++/op_bfd.h 6 Apr 2005 21:07:07 -0000 1.35 > +++ libutil++/op_bfd.h 9 Apr 2005 03:19:11 -0000 > @@ -183,7 +183,7 @@ private: > /// file size in bytes > off_t file_size; > > - // the bfd object. > + // the bfd object, NULL if the binary file can't be accessed. > bfd * ibfd; > > // The following member variables: debug_filename and dbfd are > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > > |
From: John L. <le...@mo...> - 2005-04-11 12:38:44
|
On Mon, Apr 11, 2005 at 07:27:32AM -0500, Maynard P. Johnson wrote: > OK, the seg fault is fixed in CVS now. Thanks. However, I'm still not > getting any annotated source created. Can you help with that problem, too, > Philippe? What is your exact invocation of opannotate, and what's the output of it if any? john |
From: Maynard P. J. <may...@us...> - 2005-04-11 13:09:20
|
Maynard Johnson IBM Linux Technology Center ----- Original Message ----- From: "John Levon" <le...@mo...> To: "Maynard P. Johnson" <may...@us...> Cc: "Philippe Elie" <ph...@wa...>; <opr...@li...> Sent: Monday, April 11, 2005 7:38 AM Subject: Re: opannotate broken in CVS > On Mon, Apr 11, 2005 at 07:27:32AM -0500, Maynard P. Johnson wrote: > > > OK, the seg fault is fixed in CVS now. Thanks. However, I'm still not > > getting any annotated source created. Can you help with that problem, too, > > Philippe? > > What is your exact invocation of opannotate, and what's the output of it > if any? opannotate -s -o /tmp/annotated -p /home/mpj/test_stuff -d /home/mpj/test_stuff/ With patches applied to the 0.8.1 OProfile shipped with RHEL 4, this invocation creates annotated source. Regards, -Maynard > > john > > |
From: John L. <le...@mo...> - 2005-04-11 14:08:31
|
On Mon, Apr 11, 2005 at 08:10:21AM -0500, Maynard P. Johnson wrote: > opannotate -s -o /tmp/annotated -p /home/mpj/test_stuff -d > /home/mpj/test_stuff/ And you get no output to either /tmp/annotated or on the console at all? Why are you using -p ? john |
From: John L. <le...@mo...> - 2005-04-11 14:13:42
|
On Mon, Apr 11, 2005 at 08:10:21AM -0500, Maynard P. Johnson wrote: > opannotate -s -o /tmp/annotated -p /home/mpj/test_stuff -d > /home/mpj/test_stuff/ I'm committing a fix anon. john |
From: Maynard P. J. <may...@us...> - 2005-04-11 14:20:34
|
Maynard Johnson IBM Linux Technology Center ----- Original Message ----- From: "Maynard P. Johnson" <may...@us...> To: "John Levon" <le...@mo...> Cc: "Philippe Elie" <ph...@wa...>; <opr...@li...> Sent: Monday, April 11, 2005 8:10 AM Subject: Re: opannotate broken in CVS > > Maynard Johnson > IBM Linux Technology Center > ----- Original Message ----- > From: "John Levon" <le...@mo...> > To: "Maynard P. Johnson" <may...@us...> > Cc: "Philippe Elie" <ph...@wa...>; > <opr...@li...> > Sent: Monday, April 11, 2005 7:38 AM > Subject: Re: opannotate broken in CVS > > > > On Mon, Apr 11, 2005 at 07:27:32AM -0500, Maynard P. Johnson wrote: > > > > > OK, the seg fault is fixed in CVS now. Thanks. However, I'm still not > > > getting any annotated source created. Can you help with that problem, > too, > > > Philippe? > > > > What is your exact invocation of opannotate, and what's the output of it > > if any? > opannotate -s -o /tmp/annotated -p /home/mpj/test_stuff -d > /home/mpj/test_stuff/ > With patches applied to the 0.8.1 OProfile shipped with RHEL 4, this > invocation creates annotated source. And the output is: warning: /e1000 could not be found. warning: /ext3 could not be found. warning: /jbd could not be found. warning: /oprofile could not be found. warning: /scsi_mod could not be found. warning: /sym53c8xx could not be found. warning: /usr/X11R6/bin/Xorg could not be read. warning: "/lib/ld-2.3.4.so" some functions compiled without debug information may have incorrect source line attributions no debug information available for any binary selected and --assembly not requested I guess the last line in the output is probably a clue. I did some testing of other scenarios. Here are results: - Profiling and running opannotate of either 32-bit or 64-bit test programs on RHEL 4/PPC64 successfully creates annotated source when using Red Hat's version of OProfile 0.8.1 with my patch applied (the one applied to OProfile CVS on April 4). - Using current OProfile CVS to profile and run opannotate of the same 32-bit and 64-bit programs on RHEL 4/PPC64 results in the above output and no annotated source. - Using current OProfile CVS to profile and run opannotate on an P3 Intel box successfully creates annotated source. I was quite surprised to see that current OProfile CVS works OK on Intel, but not on RHEL/PPC64. I'm going to test on SLES 9. I'll post results when I'm done. -Maynard > Regards, > -Maynard > > > > john > > > > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > > |
From: John L. <le...@mo...> - 2005-04-11 14:22:20
|
On Mon, Apr 11, 2005 at 09:21:36AM -0500, Maynard P. Johnson wrote: > I was quite surprised to see that current OProfile CVS works OK on Intel, > but not on RHEL/PPC64. I'm going to test on SLES 9. I'll post results when It's sheer chance: if the last binary looked at lacked debug info, we thought the whole selection did. I've committed the fix in CVS regards john p.s. what's the status of the Java work? Do you have a timeline? |
From: Maynard P. J. <may...@us...> - 2005-04-11 15:45:24
|
Maynard Johnson IBM Linux Technology Center ----- Original Message ----- From: "John Levon" <le...@mo...> To: "Maynard P. Johnson" <may...@us...> Cc: "Philippe Elie" <ph...@wa...>; <opr...@li...> Sent: Monday, April 11, 2005 9:22 AM Subject: Re: opannotate broken in CVS > On Mon, Apr 11, 2005 at 09:21:36AM -0500, Maynard P. Johnson wrote: > > > I was quite surprised to see that current OProfile CVS works OK on Intel, > > but not on RHEL/PPC64. I'm going to test on SLES 9. I'll post results when > > It's sheer chance: if the last binary looked at lacked debug info, we > thought the whole selection did. I've committed the fix in CVS Ok, thanks John. What file did you change (so I can see when a CVS pull will give me your fix)? > > regards > john > > p.s. what's the status of the Java work? Do you have a timeline? I think you meant to direct this question to Scott Jones, perhaps. > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > > |
From: John L. <le...@mo...> - 2005-04-11 16:05:44
|
On Mon, Apr 11, 2005 at 10:46:28AM -0500, Maynard P. Johnson wrote: > Ok, thanks John. What file did you change (so I can see when a CVS pull > will give me your fix)? 2005-04-11 John Levon <le...@mo...> * pp/opannotate.cpp: fix opannotate matching several binaries john |