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

Bug 351355

Summary: gprof: support 64-bit gmon files in ppc64
Product: [Tools] Linux Tools Reporter: Wainer dos Santos Moschetta <wainersm>
Component: GProfAssignee: Xavier Raynaud <xraynaud>
Status: RESOLVED FIXED QA Contact: Xavier Raynaud <xavier.raynaud>
Severity: major    
Priority: P3 CC: lilia.ghachem, obusatto, rsjoao
Version: 0.8.0   
Target Milestone: ---   
Hardware: Power PC   
OS: Linux   
Whiteboard:
Attachments:
Description Flags
Patch to fix the problem
obusatto: iplog+
Getting Symbol table correctly in ppc64 obusatto: iplog+

Description Wainer dos Santos Moschetta CLA 2011-07-06 12:37:10 EDT
Build Identifier: 3.6.2

Current solution to support 64-bit gmon files doesn't work in ppc64.
Refers to https://bugs.eclipse.org/bugs/show_bug.cgi?id=304163

Reproducible: Always

Steps to Reproduce:
1. Import gprofTest project from http://fedorapeople.org/~overholt/LinuxToolsTestProjects.zip in a ppc64 machine
2. Open gmon.out file
3. Result: view is displayed empty
Comment 1 Wainer dos Santos Moschetta CLA 2011-07-06 12:41:13 EDT
Created attachment 199194 [details]
Patch to fix the problem

I've tested this patch in a Power 6 machine. Working fine.
Comment 2 Andrew Overholt CLA 2011-07-06 15:51:07 EDT
Thanks for the patch, Wainer.  It looks good to me.  Ideally we'd be doing something a bit more robust to determine the word size of the CPU but this does fix the immediate issue (you say it works and it looks like it should).

I'll let Xavier apply this but if he doesn't have time, post a comment here and I'll do it.
Comment 3 Wainer dos Santos Moschetta CLA 2011-07-06 16:06:21 EDT
(In reply to comment #2)
> Thanks for the patch, Wainer.  It looks good to me.  Ideally we'd be doing
> something a bit more robust to determine the word size of the CPU but this does
> fix the immediate issue (you say it works and it looks like it should).

I've seen a weird behavior and I believe word size might be the problem.

I tested the patch by compiling an application using distro gcc (RHEL 5) and it worked fine as I mentioned. However I tried to compile using Advance Toolchain 4.x but it failed (see stacktrace below).

I guess it is somehow miscalculating pc low and high addresses. I am still trying to figure out why gmon.out being generated is different (distro vs advance toolchain) 

!MESSAGE Array index out of range: -1
!STACK 0
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: -1
        at org.eclipse.linuxtools.gprof.parser.HistogramDecoder.AssignSamplesSymbol(HistogramDecoder.java:216)
        at org.eclipse.linuxtools.gprof.parser.GmonDecoder.ReadGmonContent(GmonDecoder.java:174)
        at org.eclipse.linuxtools.gprof.parser.GmonDecoder.read(GmonDecoder.java:116)
        at org.eclipse.linuxtools.gprof.parser.GmonDecoder.read(GmonDecoder.java:106)
        at org.eclipse.linuxtools.gprof.view.GmonView.displayGprofView(GmonView.java:200)
        at org.eclipse.linuxtools.gprof.action.OpenGmonAction.open(OpenGmonAction.java:55)
        at org.eclipse.ui.internal.EditorManager$3.run(EditorManager.java:701)
        at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
        at org.eclipse.ui.internal.EditorManager.openExternalEditor(EditorManager.java:694)
        at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:668)
        at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:638)
        at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2860)
        at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2768)
....
....
Comment 4 Wainer dos Santos Moschetta CLA 2011-07-06 16:31:04 EDT
(In reply to comment #3)
> (In reply to comment #2)
> > Thanks for the patch, Wainer.  It looks good to me.  Ideally we'd be doing
> > something a bit more robust to determine the word size of the CPU but this does
> > fix the immediate issue (you say it works and it looks like it should).
> 
> I've seen a weird behavior and I believe word size might be the problem.
> 
> I tested the patch by compiling an application using distro gcc (RHEL 5) and it
> worked fine as I mentioned. However I tried to compile using Advance Toolchain
> 4.x but it failed (see stacktrace below).

I just noticed I've made a mistaken: RHEL 5 gcc, by default, generate 32-bits code although in ppc64 arch. I enforce it to generate 64-bits and now gprof plug-in is failing to distro gcc as well.

In summary: the patch alone doesn't make gprof plug-in works for 64-bits applications in ppc64.
Comment 5 Renato Stoffalette Joao CLA 2011-07-20 17:32:27 EDT
Hi.

Were there any updates on this ?
I have been trying to debug it but still not getting any success on ppc 64-bit applications.


Renato
Comment 6 Renato Stoffalette Joao CLA 2011-07-26 11:35:56 EDT
(In reply to comment #5)
> Hi.
> 
> Were there any updates on this ?
> I have been trying to debug it but still not getting any success on ppc 64-bit
> applications.
> 
> 
> Renato

Console output shows 
(In reply to comment #5)
> Hi.
> 
> Were there any updates on this ?
> I have been trying to debug it but still not getting any success on ppc 64-bit
> applications.
> 
> 
> Renato


For some reason the decodeCallGraphRecord() is always assigning null to childSymbol and parentSymbol in CallGraphDecoder.java. and then GmonDecoder throws the EOFException prematurly.
Comment 7 Renato Stoffalette Joao CLA 2011-07-26 13:20:09 EDT
(In reply to comment #6)
> (In reply to comment #5)
> > Hi.
> > 
> > Were there any updates on this ?
> > I have been trying to debug it but still not getting any success on ppc 64-bit
> > applications.
> > 
> > 
> > Renato
> 
> Console output shows 
> (In reply to comment #5)
> > Hi.
> > 
> > Were there any updates on this ?
> > I have been trying to debug it but still not getting any success on ppc 64-bit
> > applications.
> > 
> > 
> > Renato
> 
> 
> For some reason the decodeCallGraphRecord() is always assigning null to
> childSymbol and parentSymbol in CallGraphDecoder.java. and then GmonDecoder
> throws the EOFException prematurly.



And By the way I am getting this output from console.

!ENTRY org.eclipse.linuxtools.gprof 4 4 2011-07-26 11:32:25.270
!MESSAGE 
!STACK 0
java.io.EOFException
	at java.io.DataInputStream.readShort(DataInputStream.java:309)
	at org.eclipse.linuxtools.gprof.parser.HistogramDecoder.decodeHistRecord(HistogramDecoder.java:186)
	at org.eclipse.linuxtools.gprof.parser.GmonDecoder.ReadGmonContent(GmonDecoder.java:185)
	at org.eclipse.linuxtools.gprof.parser.GmonDecoder.read(GmonDecoder.java:129)
	at org.eclipse.linuxtools.gprof.view.GmonView.displayGprofView(GmonView.java:210)
	at org.eclipse.linuxtools.gprof.action.OpenGmonAction.open(OpenGmonAction.java:55)
	at org.eclipse.ui.internal.EditorManager$3.run(EditorManager.java:701)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.ui.internal.EditorManager.openExternalEditor(EditorManager.java:694)
	at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:668)
	at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:638)
	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2860)
	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2768)
	at org.eclipse.ui.internal.WorkbenchPage.access$11(WorkbenchPage.java:2760)
	at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2711)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2707)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2691)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2682)
	at org.eclipse.ui.ide.IDE.openEditor(IDE.java:651)
	at org.eclipse.ui.ide.IDE.openEditor(IDE.java:610)
	at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:365)
	at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:168)
	at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:229)
	at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:208)
	at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:274)
	at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:250)
	at org.eclipse.jdt.internal.ui.navigator.OpenAndExpand.run(OpenAndExpand.java:49)
	at org.eclipse.ui.actions.RetargetAction.run(RetargetAction.java:221)
	at org.eclipse.ui.navigator.CommonNavigatorManager$3.open(CommonNavigatorManager.java:185)
	at org.eclipse.ui.OpenAndLinkWithEditorHelper$InternalListener.open(OpenAndLinkWithEditorHelper.java:48)
	at org.eclipse.jface.viewers.StructuredViewer$2.run(StructuredViewer.java:845)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49)
	at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
	at org.eclipse.jface.viewers.StructuredViewer.fireOpen(StructuredViewer.java:843)
	at org.eclipse.jface.viewers.StructuredViewer.handleOpen(StructuredViewer.java:1131)
	at org.eclipse.ui.navigator.CommonViewer.handleOpen(CommonViewer.java:462)
	at org.eclipse.jface.viewers.StructuredViewer$6.handleOpen(StructuredViewer.java:1235)
	at org.eclipse.jface.util.OpenStrategy.fireOpenEvent(OpenStrategy.java:264)
	at org.eclipse.jface.util.OpenStrategy.access$2(OpenStrategy.java:258)
	at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:298)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3540)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3161)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
	at java.lang.reflect.Method.invoke(Method.java:611)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1408)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1384)
Comment 8 Andrew Overholt CLA 2011-09-30 15:17:54 EDT
Updating Xavier's email address for existing bugs.
Comment 9 Otavio Pontes CLA 2011-10-19 09:18:19 EDT
Created attachment 205525 [details]
Getting Symbol table correctly in ppc64

In ppc64 architecture the symbol table points to a data structure that
contains the pointer to the real function code in text section.
This patch adds a class to use the real pointer instead of the symbol
table pointer in gprof.
Comment 10 Otavio Pontes CLA 2011-10-19 09:20:54 EDT
Last patch I send fixes the reported problem. It must be applied after Wainer's patch.
Comment 11 Xavier Raynaud CLA 2011-10-19 10:16:42 EDT
I've pushed these 2 patches into git master.
Note that the code seems OK to me, but I've no way to test it (no ppc64 machine here).