| Summary: | gprof: support 64-bit gmon files in ppc64 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] Linux Tools | Reporter: | Wainer dos Santos Moschetta <wainersm> | ||||||
| Component: | GProf | Assignee: | 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
Wainer dos Santos Moschetta
Created attachment 199194 [details]
Patch to fix the problem
I've tested this patch in a Power 6 machine. Working fine.
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. (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) .... .... (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. 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 (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. (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) Updating Xavier's email address for existing bugs. 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.
Last patch I send fixes the reported problem. It must be applied after Wainer's patch. 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). |