Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 273337

Summary:	[opxml] reduce opxml's reliance on internal oprofile data structures
Product:	z_Archived	Reporter:	Kent Sebastian <ksebasti>
Component:	LinuxTools	Assignee:	OProfile Inbox <linux.oprofile-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	anna.dushistova, ksebasti, linux.oprofile-inbox, overholt, peter.liu, sgehwolf, wcohen
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Kent Sebastian

2009-04-22 15:59:40 EDT

Short Story:
(Re-)Investigate how useful opreport xml output is, coerce upstream for changes if necessary.

Long Story:
Currently opxml uses oprofile libraries to read the sample files directly and uses library functions to aggregate data and form custom xml for use with the plugin.

This is a problem because the internal structures aren't stable and there was talk on the oprofile mailing list (can't find a reference) how any gui should only use the xml output. Unfortunately the last time I looked into the xml output, there was far too much of it at far too low of a signal-to-noise ratio. But the existence of opxml has been a bit of a headache; it would be nice to not have a native component at all.

Use this bug as a tracker for progress on this front.

Comment 1 Kent Sebastian

2009-04-28 17:07:05 EDT

*** Bug 273871 has been marked as a duplicate of this bug. ***

Comment 2 William Cohen

2009-06-01 16:40:13 EDT

This thread discusses using xml rather than shared library:

http://marc.info/?l=oprofile-list&m=122936314525103&w=2

Comment 3 Kent Sebastian

2009-06-10 11:00:14 EDT

Another big part of opxml is grabbing the line numbers from the binaries profiled by oprofile. Elliott just pointed me to the addr2line tool (http://sourceware.org/binutils/docs/binutils/addr2line.html), part of the binutils package which could probably replace this function. Along with using only xml output, this could be a big step to removing the reliance on this native component.

Comment 4 Roland Grunberg

2010-08-23 14:13:48 EDT

Revision #25379 is a step in the right direction. This eliminates the need for opxml and instead uses tools/files such as opcontrol, opreport, ophelp, addr2line, /dev/oprofile, /usr/share/oprofile to generate the xml needed to be parsed. All that's left to do would be remove the opxml dependent projects (o.e.l.oprofile.core.${arch} and the opxml source code, and update the documentation page removing references to compiling opxml).

Comment 5 Anna Dushistova

2011-02-10 04:57:47 EST

Hi All,
is the last comment still valid?
Here is what I see in Oprofile#getEvents with the latest sources from trunk(rev 27185):
RunnableWithProgress opxml = OprofileCorePlugin.getDefault().getOpxmlProvider().sessions(sessionList);
opxml.run(null);

Guess that means it's still in use...

Comment 6 Severin Gehwolf

2011-02-10 09:33:14 EST

(In reply to comment #5)
> Hi All,

Hi,

> is the last comment still valid?

Yes, opxml has been removed in trunk and the upcoming 0.7 release.

> Here is what I see in Oprofile#getEvents with the latest sources from trunk(rev
> 27185):
> RunnableWithProgress opxml =
> OprofileCorePlugin.getDefault().getOpxmlProvider().sessions(sessionList);
> opxml.run(null);
>
> Guess that means it's still in use...

Actually, it's not. For trunk you shouldn't need to compile opxml anymore (though, you still need the symlink to consolehelper or equivalent).

Having said that, there's still some clean-up required as mentioned in Rolands comment.

Comment 7 Severin Gehwolf

2011-02-16 09:44:07 EST

Documentation has been updated and opxml sources have been removed, which should complete opxml removal.

Comment 8 Severin Gehwolf

2011-02-16 09:46:07 EST

Closing.