From mark@klomp.org Mon Jul 2 12:32:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 02 Jul 2007 12:32:00 -0000 Subject: inner classes with fields names similar to outer class/method fields Message-ID: <1183379510.3622.17.camel@dijkstra.wildebeest.org> Hi, The following bug cost me a while to track down. The fix is easy. But if you are not expecting this then you might be puzzled about it for a long time like I was. testSyscallRunning(frysk.proc.TestSyscallRunning)java.lang.NullPointerException at frysk.proc.TestSyscallRunning$2.execute(TestRunner) The problem was that under some versions of the fc6 compiler this method was miscompiled (!), under f7 the compiler gets it right. The anonymous inner class that extends TaskEvent tries to refer to the final task field of the method it is in. But TaskEvent has a field called task itself. The TaskEvent.task field is never initialized and so stays null. By explicitly renaming the final field in the outer method and using that name in the inner class the reference is always correct (under either the fc6 or f7 compiler). 2007-06-02 Mark Wielaard * TestSyscallRunning.java (testSyscallRunning): Rename final task field to proc_task. There should be a warning in the compiler to complain if such a confusing name clash is detected. Cheers, Mark diff -u -r1.12 TestSyscallRunning.java --- frysk/proc/TestSyscallRunning.java 17 Apr 2007 19:45:09 -0000 1.12 +++ frysk/proc/TestSyscallRunning.java 2 Jul 2007 12:16:10 -0000 @@ -103,10 +103,10 @@ // Get the port that will be listened on. int port = Integer.decode(in.readLine()).intValue(); - final Task task = proc.getMainTask(); + final Task proc_task = proc.getMainTask(); - final SyscallObserver syso = new SyscallObserver("accept", task, false); - task.requestAddSyscallObserver(syso); + final SyscallObserver syso = new SyscallObserver("accept", proc_task, false ); + proc_task.requestAddSyscallObserver(syso); // Make sure the observer is properly installed. while (! syso.isAdded()) @@ -122,15 +122,15 @@ // Now unblock and then attach another observer. // Do all this on the eventloop so properly serialize calls. - final SyscallObserver syso2 = new SyscallObserver("accept", task, true); + final SyscallObserver syso2 = new SyscallObserver("accept", proc_task, true ); Manager.eventLoop.add(new TaskEvent() { public void execute () { // Continue running (inside syscall), // while attaching another syscall observer - task.requestUnblock(syso); - task.requestAddSyscallObserver(syso2); + proc_task.requestUnblock(syso); + proc_task.requestAddSyscallObserver(syso2); } }); From mark@klomp.org Mon Jul 2 16:06:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 02 Jul 2007 16:06:00 -0000 Subject: What does brokenIfUtraceXXX() test for? Message-ID: <1183392408.3622.24.camel@dijkstra.wildebeest.org> Hi, I am seeing two failures on 2.6.21-1.3228.fc7 x86 SMP: testTerminateKillKILL(frysk.proc.TestTaskTerminateObserver)junit.framework.AssertionFailedError: terminating value expected:<-9> but was:<128> testTerminatingKillKILL(frysk.proc.TestTaskTerminateObserver)junit.framework.AssertionFailedError: terminating value expected:<-9> but was:<128> That are guarded by brokenIfUtraceXXX() which has as explanation: /** * A method that returns true, and prints broken, when the build * kernel includes UTRACE. */ So, tests guarded by that ever never expected to succeed with utrace enabled? Or is it more subtle than that? Both bugs referenced through these guards (#3525 and #3489) are closed already. Cheers, Mark From mark@klomp.org Tue Jul 3 10:06:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 03 Jul 2007 10:06:00 -0000 Subject: libgcj update troubles on fc6 Message-ID: <1183457192.3599.25.camel@dijkstra.wildebeest.org> Hi, Seeing there was an updated package for gcc on my FC6 machine I happily let the thing update itself. However libgcj breaks while updating: Updating : libgcj ######################### [1/2] error: unpacking of archive failed on file /usr/lib/gcj-4.1.2: cpio: rename Updated: libgcj.i386 0:4.1.2-13.fc6 Complete! Notice the happy "Complete!"... Your resulting gcj environment is now complete borked. gcj -C Hello.java Hello.java:0: error: Can't find default package ?java.lang?. Check the CLASSPATH environment variable and the access to the archives 1 error And any attempt to install or update (even after a remove) of libgcj will fail in the same way. For some reason there are multiple /usr/lib/gcj-4.1.2;468a1711 dirs (with the part after ; being some random hex-string) which seem to prevent yum updating or installing anything. In the end the only way to get a working install back was to yum remove libgcj (yes, this takes all the dependencies with it), and then removing the left over directories rm -rf /usr/lib/gcj-4.1.2* /usr/lib64/gcj-4.1.2* And then installing everything again with yum install. There probably is an easier (and safer) way, and I don't really understand why this happened in the first place. Comments and ideas appreciated. Thanks, Mark From mark@klomp.org Tue Jul 3 10:36:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 03 Jul 2007 10:36:00 -0000 Subject: frysk-core/frysk/proc/dead ChangeLog LinuxProc ... In-Reply-To: <20070703013351.32319.qmail@sourceware.org> References: <20070703013351.32319.qmail@sourceware.org> Message-ID: <1183458993.3599.28.camel@dijkstra.wildebeest.org> Hi Phil, On Tue, 2007-07-03 at 01:33 +0000, pmuldoon@sourceware.org wrote: > Log message: > 2007-07-02 Phil Muldoon > > * LinuxTask.java (LinuxTask): Take FP Register data as a > parameter. > (sendrecRegisterBanks): Rewrite to either present a blank > page or actual register data. > * LinuxProc.java (sendRefresh):Account for two different > optimizations in floating point note data. > * TestLinuxCore.java (testLinuxCoreFileMaps) Remove runPending() > and requestRefresh calls. > (testLinuxCoreFileStackTrace): Ditto. > (testLinuxHostPopulation): Ditto. > (testLinuxProcPopulation): Ditto. > (testLinuxProcAuxV): Ditto. > (testLinuxTaskMemory): Ditto. > (testLinuxTaskPopulation): Ditto. It looks like this introduced 2 failures on my setup (FC6 x86_64 SMP): There were 2 errors: 1) testLinuxCoreFileMaps(frysk.proc.dead.TestLinuxCore)java.lang.ArrayIndexOutOfBoundsException: 336 at inua.eio.ArrayByteBuffer.peek(TestRunner) at inua.eio.ByteBuffer.peek(TestRunner) at inua.eio.ByteBuffer.peekFully(TestRunner) at inua.eio.ByteBuffer.peekLittle(TestRunner) at inua.eio.ByteBuffer.peekLittle(TestRunner) at inua.eio.ByteOrdered$2.peekInt(TestRunner) at inua.eio.ByteBuffer.getInt(TestRunner) at lib.elf.ElfPrstatus.(TestRunner) at lib.elf.ElfPrstatus.decode(TestRunner) at frysk.proc.dead.LinuxProc.sendRefresh(TestRunner) at frysk.proc.dead.LinuxHost.sendRefresh(TestRunner) at frysk.proc.dead.LinuxHost.(TestRunner) at frysk.proc.dead.TestLinuxCore.testLinuxCoreFileMaps(TestRunner) at frysk.junit.Runner.runCases(TestRunner) at frysk.junit.Runner.runArchCases(TestRunner) at frysk.junit.Runner.runTestCases(TestRunner) at TestRunner.main(TestRunner) 2) testLinuxCoreFileStackTrace(frysk.proc.dead.TestLinuxCore)java.lang.ArrayIndexOutOfBoundsException: 336 at inua.eio.ArrayByteBuffer.peek(TestRunner) at inua.eio.ByteBuffer.peek(TestRunner) at inua.eio.ByteBuffer.peekFully(TestRunner) at inua.eio.ByteBuffer.peekLittle(TestRunner) at inua.eio.ByteBuffer.peekLittle(TestRunner) at inua.eio.ByteOrdered$2.peekInt(TestRunner) at inua.eio.ByteBuffer.getInt(TestRunner) at lib.elf.ElfPrstatus.(TestRunner) at lib.elf.ElfPrstatus.decode(TestRunner) at frysk.proc.dead.LinuxProc.sendRefresh(TestRunner) at frysk.proc.dead.LinuxHost.sendRefresh(TestRunner) at frysk.proc.dead.LinuxHost.(TestRunner) at frysk.proc.dead.TestLinuxCore.testLinuxCoreFileStackTrace(TestRunner) at frysk.junit.Runner.runCases(TestRunner) at frysk.junit.Runner.runArchCases(TestRunner) at frysk.junit.Runner.runTestCases(TestRunner) at TestRunner.main(TestRunner) Could you take a look? Thanks, Mark From pmuldoon@redhat.com Tue Jul 3 14:52:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 03 Jul 2007 14:52:00 -0000 Subject: frysk-core/frysk/proc/dead ChangeLog LinuxProc ... In-Reply-To: <1183458993.3599.28.camel@dijkstra.wildebeest.org> References: <20070703013351.32319.qmail@sourceware.org> <1183458993.3599.28.camel@dijkstra.wildebeest.org> Message-ID: <468A628B.7020202@redhat.com> Mark Wielaard wrote: > Hi Phil, > > On Tue, 2007-07-03 at 01:33 +0000, pmuldoon@sourceware.org wrote: > >> Log message: >> 2007-07-02 Phil Muldoon >> >> * LinuxTask.java (LinuxTask): Take FP Register data as a >> parameter. >> (sendrecRegisterBanks): Rewrite to either present a blank >> page or actual register data. >> * LinuxProc.java (sendRefresh):Account for two different >> optimizations in floating point note data. >> * TestLinuxCore.java (testLinuxCoreFileMaps) Remove runPending() >> and requestRefresh calls. >> (testLinuxCoreFileStackTrace): Ditto. >> (testLinuxHostPopulation): Ditto. >> (testLinuxProcPopulation): Ditto. >> (testLinuxProcAuxV): Ditto. >> (testLinuxTaskMemory): Ditto. >> (testLinuxTaskPopulation): Ditto. >> > > It looks like this introduced 2 failures on my setup (FC6 x86_64 SMP): > Sure. Can you create a bugzilla please. Regards Phil From mark@klomp.org Tue Jul 3 15:07:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 03 Jul 2007 15:07:00 -0000 Subject: frysk-core/frysk/proc/dead ChangeLog LinuxProc ... In-Reply-To: <468A628B.7020202@redhat.com> References: <20070703013351.32319.qmail@sourceware.org> <1183458993.3599.28.camel@dijkstra.wildebeest.org> <468A628B.7020202@redhat.com> Message-ID: <1183475208.3599.30.camel@dijkstra.wildebeest.org> On Tue, 2007-07-03 at 09:51 -0500, Phil Muldoon wrote: > Sure. Can you create a bugzilla please. Here you go: http://sourceware.org/bugzilla/show_bug.cgi?id=4728 Thanks, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cagney@redhat.com Tue Jul 3 15:27:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 03 Jul 2007 15:27:00 -0000 Subject: No meeting Wednesday 2007-07-04 (US July 4th) Message-ID: <468A6923.4030307@redhat.com> With a significant number of developers taking a July 4th Holiday, I don't think there's any sense in holding a meeting tomorrow. We can pick things up in a week. From cagney@redhat.com Tue Jul 3 15:34:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 03 Jul 2007 15:34:00 -0000 Subject: inner classes with fields names similar to outer class/method fields In-Reply-To: <1183379510.3622.17.camel@dijkstra.wildebeest.org> References: <1183379510.3622.17.camel@dijkstra.wildebeest.org> Message-ID: <468A6C78.9050307@redhat.com> Mark Wielaard wrote: > Hi, > > The following bug cost me a while to track down. The fix is easy. But if > you are not expecting this then you might be puzzled about it for a long > time like I was. > > testSyscallRunning(frysk.proc.TestSyscallRunning)java.lang.NullPointerException > at frysk.proc.TestSyscallRunning$2.execute(TestRunner) > > The problem was that under some versions of the fc6 compiler this method > was miscompiled (!), under f7 the compiler gets it right. The anonymous > inner class that extends TaskEvent tries to refer to the final task > field of the method it is in. But TaskEvent has a field called task > itself. The TaskEvent.task field is never initialized and so stays null. > By explicitly renaming the final field in the outer method and using > that name in the inner class the reference is always correct (under > either the fc6 or f7 compiler). > Mark, Can you be more specific? Frysk's build system already has a check for what sounds like a very similar bug vis: class foo { { func1() { class Bar {} } func2() { class Bar {} } } Andrew From ajocksch@redhat.com Tue Jul 3 16:19:00 2007 From: ajocksch@redhat.com (Adam Jocksch) Date: Tue, 03 Jul 2007 16:19:00 -0000 Subject: Deleting a Display Message-ID: <468A771B.1030907@redhat.com> Now that we can create expression displays with the hpd, what should the syntax be to delete a display? 'delete' is currently being used to remove breakpoints, should it work with displays as well? The other thought I had was something like display remove . Any other ideas/suggestions? Adam From mark@klomp.org Tue Jul 3 17:27:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 03 Jul 2007 17:27:00 -0000 Subject: inner classes with fields names similar to outer class/method fields In-Reply-To: <468A6C78.9050307@redhat.com> References: <1183379510.3622.17.camel@dijkstra.wildebeest.org> <468A6C78.9050307@redhat.com> Message-ID: <1183483619.3599.41.camel@dijkstra.wildebeest.org> Hi Andrew, On Tue, 2007-07-03 at 11:34 -0400, Andrew Cagney wrote: > Mark Wielaard wrote: > > The anonymous > > inner class that extends TaskEvent tries to refer to the final task > > field of the method it is in. But TaskEvent has a field called task > > itself. The TaskEvent.task field is never initialized and so stays null. > > > Can you be more specific? Look at the attached patch of the original message, in particular: > - final Task task = proc.getMainTask(); > + final Task proc_task = proc.getMainTask(); > [...] > Manager.eventLoop.add(new TaskEvent() > { > public void execute () > { > // Continue running (inside syscall), > // while attaching another syscall observer > - task.requestUnblock(syso); > - task.requestAddSyscallObserver(syso2); > + proc_task.requestUnblock(syso); > + proc_task.requestAddSyscallObserver(syso2); > } > }); Now look at TaskEvent: > public abstract class TaskEvent > implements Event > { > [...] > protected Task task; > [...] And ask yourself which 'task' is being referred to in the execute() method of the anonymous class given to the add() method. Is it the final field in the outer class method called task, or is it the inherited protected field called task from the super class TaskEvent? The "right" answer is the protected field task from the super class, but since that is in a completely different file while the final field task in the enclosing method looks like the only task in scope some confusion ensues. Renaming (one of) the fields is the best solution seeing some compilers also seem to get this one wrong. Cheers, Mark From ajocksch@redhat.com Tue Jul 3 17:42:00 2007 From: ajocksch@redhat.com (Adam Jocksch) Date: Tue, 03 Jul 2007 17:42:00 -0000 Subject: Displays in the GUI Message-ID: <468A8A86.2060701@redhat.com> Also ahead on the roadmap for DisplayValues is how to integrate them into the source window. My first impression would be to use the current Varaible Watches pane, maybe adding a text field so that more complicated expressions could be input. This would be similar to the Watch Expression view for Insight. I've attached a screenshot from insight as well as a screenshot of what this could look like under Frysk. -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk_watch.png Type: image/png Size: 52403 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: insight_scrnsht.png Type: image/png Size: 30478 bytes Desc: not available URL: From ajocksch@redhat.com Tue Jul 3 17:54:00 2007 From: ajocksch@redhat.com (Adam Jocksch) Date: Tue, 03 Jul 2007 17:54:00 -0000 Subject: Deleting a Display In-Reply-To: <468A771B.1030907@redhat.com> References: <468A771B.1030907@redhat.com> Message-ID: <468A8D2F.1000302@redhat.com> Adam Jocksch wrote: > Now that we can create expression displays with the hpd, what should > the syntax be to delete a display? 'delete' is currently being used to > remove breakpoints, should it work with displays as well? The other > thought I had was something like display remove . > > Any other ideas/suggestions? > > Adam Looking through the hpd I see the following: > delete {actionpoint-list | -enabled | -disabled | -break | -watch | -barrier | -all} > actions {actionpoint-list | -enabled | -disabled | -break | -watch | -barrier} > disable {actionpoint-list | -enabled | -disabled | -break | -watch | -barrier} > enable {actionpoint-list | -enabled | -disabled | -break | -watch | -barrier} It seems to me that we want all of these to apply to displays as well. Is there any particular reason that we shouldn't do this? Otherwise I'll move ahead and implement them. Adam From cagney@redhat.com Tue Jul 3 18:34:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 03 Jul 2007 18:34:00 -0000 Subject: Deleting a Display In-Reply-To: <468A8D2F.1000302@redhat.com> References: <468A771B.1030907@redhat.com> <468A8D2F.1000302@redhat.com> Message-ID: <468A96CC.4030609@redhat.com> Adam Jocksch wrote: > Adam Jocksch wrote: >> Now that we can create expression displays with the hpd, what should >> the syntax be to delete a display? 'delete' is currently being used >> to remove breakpoints, should it work with displays as well? The >> other thought I had was something like display remove . >> >> Any other ideas/suggestions? >> >> Adam > Looking through the hpd I see the following: > > delete {actionpoint-list | -enabled | -disabled | -break | -watch | > -barrier | -all} > > actions {actionpoint-list | -enabled | -disabled | -break | -watch > | -barrier} > > disable {actionpoint-list | -enabled | -disabled | -break | -watch > | -barrier} > > enable {actionpoint-list | -enabled | -disabled | -break | -watch | > -barrier} > > It seems to me that we want all of these to apply to displays as well. > Is there any particular reason that we shouldn't do this? Otherwise > I'll move ahead and implement them. I can't think of one :-) "delete " would seem very intuitive. Andrew > From cagney@redhat.com Tue Jul 3 18:44:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 03 Jul 2007 18:44:00 -0000 Subject: inner classes with fields names similar to outer class/method fields In-Reply-To: <1183483619.3599.41.camel@dijkstra.wildebeest.org> References: <1183379510.3622.17.camel@dijkstra.wildebeest.org> <468A6C78.9050307@redhat.com> <1183483619.3599.41.camel@dijkstra.wildebeest.org> Message-ID: <468A990C.8060409@redhat.com> Mark Wielaard wrote: > > And ask yourself which 'task' is being referred to in the execute() > method of the anonymous class given to the add() method. Is it the final > field in the outer class method called task, or is it the inherited > protected field called task from the super class TaskEvent? The "right" > answer is the protected field task from the super class, but since that > is in a completely different file while the final field task in the > enclosing method looks like the only task in scope some confusion > ensues. Renaming (one of) the fields is the best solution seeing some > compilers also seem to get this one wrong. > Ok, this is a very different problem; I have my doubts that jv-scan could be used to detect this. Can you create a frysk bug to track it and a test case for reference? Andrew > Cheers, > > Mark > > From cmoller@redhat.com Tue Jul 3 18:47:00 2007 From: cmoller@redhat.com (Chris Moller) Date: Tue, 03 Jul 2007 18:47:00 -0000 Subject: Deleting a Display In-Reply-To: <468A96CC.4030609@redhat.com> References: <468A771B.1030907@redhat.com> <468A8D2F.1000302@redhat.com> <468A96CC.4030609@redhat.com> Message-ID: <468A99A6.1080303@redhat.com> Andrew Cagney wrote: > Adam Jocksch wrote: >> >> It seems to me that we want all of these to apply to displays as >> well. Is there any particular reason that we shouldn't do this? >> Otherwise I'll move ahead and implement them. > > I can't think of one :-) "delete " would seem very > intuitive. eradicate ? expunge ? eliminate-with-extreme-prejudice ? > > Andrew > >> > -- Chris Moller Java: the blunt scissors of programming languages. -- Dave Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From mark@klomp.org Tue Jul 3 19:21:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 03 Jul 2007 19:21:00 -0000 Subject: inner classes with fields names similar to outer class/method fields In-Reply-To: <468A990C.8060409@redhat.com> References: <1183379510.3622.17.camel@dijkstra.wildebeest.org> <468A6C78.9050307@redhat.com> <1183483619.3599.41.camel@dijkstra.wildebeest.org> <468A990C.8060409@redhat.com> Message-ID: <1183490473.3599.50.camel@dijkstra.wildebeest.org> On Tue, 2007-07-03 at 14:44 -0400, Andrew Cagney wrote: > Ok, this is a very different problem; I have my doubts that jv-scan > could be used to detect this. Note that jv-scan isn't supported (or bundled in recent Fedoras) anymore. > Can you create a frysk bug to track it > and a test case for reference? There you go: http://sourceware.org/bugzilla/show_bug.cgi?id=4735 You can create a testcase from the patch and explanation I posted. Code like that is confusing and should be avoided altogether. Cheers, Mark From cagney@redhat.com Tue Jul 3 21:52:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 03 Jul 2007 21:52:00 -0000 Subject: test case, exceptions, and tearDown Message-ID: <468AC518.8050101@redhat.com> Just FYI, Todays IRC had a bit of discussion regarding how a JUnit test is written (as a style thing). I've found the JUnit faq ( http://junit.sourceforge.net/doc/faq/faq.htm ), even though it is using version 4 code, makes for a good reference for how the authors intended the framework to be used. Two answers I found useful: > *How do I write a test that fails when an unexpected exception is > thrown?* > > Declare the exception in the |throws| clause of the test method and > don't catch the exception within the test method. Uncaught exceptions > will cause the test to fail with an error. > > The following is an example test that fails when the > |IndexOutOfBoundsException| is raised: > > | > > @Test > public void testIndexOutOfBoundsExceptionNotRaised() > throws IndexOutOfBoundsException { > > ArrayList emptyList = new ArrayList(); > Object o = emptyList.get(0); > } > | Notice how the exception doesn't need to be explicitly caught; instead the exception being thrown is interpreted as a FAIL. and: > *When are tests garbage collected?* > > /(Submitted by: Timothy Wall and Kent Beck)/ > > By design, the tree of Test instances is built in one pass, then the > tests are executed in a second pass. The test runner holds strong > references to all Test instances for the duration of the test > execution. This means that for a very long test run with many Test > instances, none of the tests may be garbage collected until the end of > the entire test run. > > Therefore, if you allocate external or limited resources in a test, > you are responsible for freeing those resources. Explicitly setting an > object to |null| in the |tearDown()| method, for example, allows it to > be garbage collected before the end of the entire test run. > Things involving file-descriptors would certainly fall into that category. Something to keep an eye out for :-) Andrew From kris.van.hees@oracle.com Tue Jul 3 23:05:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Tue, 03 Jul 2007 23:05:00 -0000 Subject: test case, exceptions, and tearDown In-Reply-To: <468AC518.8050101@redhat.com> References: <468AC518.8050101@redhat.com> Message-ID: <20070703230452.GA3786@ca-server1.us.oracle.com> While I agree in principle with the things you quote below, and in general with most of the junit FAQ (as I have for many years), I do also believe that we shouldn't necessarily blindly follow whatever is stated in the FAQ. I mean that in very generic terms: the purpose of having a testsuite is to provide us with clear, consistent, and above all useful results. One thing I have always had an issue with concerning junit is the blending of ERROR and FAIL in junit 4. I believe that the distinction between a failed test (assertions failed or expected failure mode (e.g. exception) occcured) and a test execution that failed (unexpected event caused the test to not complete as expected, i.e. something made it impossible to make a correct PASS/FAIL determination). In that sense, I do not think it to be wise to always take the strict rule of just letting exceptions bubble up to the framework. To me, the most important word in the FAQ about this topic is "unexpected". If there is an exception that is known to validly occur in a failure scenario (it makes the test fail to satisfy it assertions) then that should be reflected in the result differently from an unexpected exception that interferes with the test execution. There are obviously different schools of thought, but given that Frysk is already using 2 testing frameworks that are set up to return results that fall within the POSIX categories (as described in the dejagnu documentation as reference - discussed in past months), it would make sense that we make use of the full spectrum of result messages in a meaningful way. Cheers, Kris On Tue, Jul 03, 2007 at 05:52:24PM -0400, Andrew Cagney wrote: > Just FYI, > > Todays IRC had a bit of discussion regarding how a JUnit test is written > (as a style thing). I've found the JUnit faq ( > http://junit.sourceforge.net/doc/faq/faq.htm ), even though it is using > version 4 code, makes for a good reference for how the authors intended > the framework to be used. > > Two answers I found useful: > > >*How do I write a test that fails when an unexpected exception is > >thrown?* > > > >Declare the exception in the |throws| clause of the test method and > >don't catch the exception within the test method. Uncaught exceptions > >will cause the test to fail with an error. > > > >The following is an example test that fails when the > >|IndexOutOfBoundsException| is raised: > > > >| > > > > @Test > > public void testIndexOutOfBoundsExceptionNotRaised() > > throws IndexOutOfBoundsException { > > > > ArrayList emptyList = new ArrayList(); > > Object o = emptyList.get(0); > > } > > | > Notice how the exception doesn't need to be explicitly caught; instead > the exception being thrown is interpreted as a FAIL. > > and: > > >*When are tests garbage collected?* > > > >/(Submitted by: Timothy Wall and Kent Beck)/ > > > >By design, the tree of Test instances is built in one pass, then the > >tests are executed in a second pass. The test runner holds strong > >references to all Test instances for the duration of the test > >execution. This means that for a very long test run with many Test > >instances, none of the tests may be garbage collected until the end of > >the entire test run. > > > >Therefore, if you allocate external or limited resources in a test, > >you are responsible for freeing those resources. Explicitly setting an > >object to |null| in the |tearDown()| method, for example, allows it to > >be garbage collected before the end of the entire test run. > > > Things involving file-descriptors would certainly fall into that > category. Something to keep an eye out for :-) > > > Andrew > From mark@klomp.org Wed Jul 4 18:20:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 04 Jul 2007 18:20:00 -0000 Subject: Breakpoint stepping Message-ID: <1183573205.3598.157.camel@dijkstra.wildebeest.org> As you might have noticed over the last week I have dropped in the new breakpoint stepping framework (or hopefully you didn't notice since I did try to do it in chunks that all had no detectable functional behavior changes). This is an update to my previous general stepping overview http://sourceware.org/ml/frysk/2007-q2/msg00283.html and a request for review of the next steps with regard to the instruction parsers, testframework and what to use as ssol area. The main difference with the previous stepping overview regarding the ptrace state machine is that there is now an explicit Stepping state, which is a sub-state of Running and that Running.sendContinue() now not only determines how to instruct ptrace to continue the task, but also returns a different Running state based on whether or not we asked for a continue or step-continue. This makes interpreting the cause of the trap event we subsequently expect to get easier. This was previously recorded as a field in the Task itself. With respect to breakpoints the ptrace task states have been adapted to all call setupSteppingBreakpoint() after a breakpoint hit has been detected, which makes sure the PC is setup correctly (which previously could be off by one on some architectures) and to mark the Task as being at that particular breakpoint (this is still kept as Task field for now) and to not actually call Breakpoint.prepareStep(), which is now handled in Running.sendContinue(). In the previous version when reset-breakpoint stepping was used another task could miss the breakpoint if the Task moved into a Blocked state before continuing. All the logic of how to breakpoint step has been moved into the Breakpoint class that checks the properties of a new Instruction class object which is created by the Isa through an instruction parser before the breakpoint is inserted at a given location (previously we represented instructions just as a byte[]). An Instruction knows how long the instruction is, which bytes it represents, whether it can be single stepped out of line and how to set that up given the original pc location and an alternative address, plus any fixups that are needed to the Task afterwards (and it has a notion of whether or not the Instruction can be simulated, but that isn't currently used, see below). A Breakpoint ties an Instruction to a particular address and Proc (and Tasks can have zero or more Breakpoints, they share the same Breakpoint on the same address with other Tasks of a Proc and when no Tasks of a Proc has an Breakpoint at a particular address anymore the Breakpoint is removed). For stepping the Breakpoint the Running.sendContinue() method first calls Breakpoint.prepareStep(), then signals ptrace to do a single step of the Task, putting the Task in Stepping state and then in handleTrapEvent() calls Breakpoint.stepDone(). prepareStep() queries the capabilities of the Instruction at the pc address and depending on that either sets things up for doing a step out of line, simulate the instruction (but none of the current Instructions have been setup to do simulation yes, and look at the comment in prepareStep() to see what is needed to fully enable this option) or reset the current Instruction (removing the breakpoint instruction temporarily). Accordingly a Breakpoint can be in the state NOT_STEPPING, OUT_OF_LINE_STEPPING, SIMULATE_STEPPING or RESET_STEPPING. In the case of RESET_STEPPING (which was the only option we supported before) other Tasks might miss and just past the Breakpoint during the brief period between the reset, step and reinstall. Breakpoint prepareStep() just takes the Instruction bytes and puts them at the current pc address, and doneStep() reinstates the breakpoint instruction. When the Instruction supports single step out of line then the Breakpoint requests an address in the single step out of line area of the Proc, instructs the Instruction to install itself there for the current Task calling Instruction.setupExecuteOutOfLine(). The default action of setupExecuteOutOfLine() is to set the pc to the given address and place a copy the instruction bytes there (although this can be overridden if an Instruction wants to do something more fancy). When the task signals the Breakpoint that a step was taken by calling stepDone(), the Breakpoint calls Instruction fixupExecuteOutOfLine() with the original pc and replacement address so any adjustments can be done to the Task registers. The default action is to just set the pc to the original pc plus the length of the Instruction just stepped. But Instructions can override that if more is needed. As an example the RET instruction doesn't do any fixup (since the only action is setting the pc to the right location in the first place) and the JMP instruction sets the pc to original pc plus/minus the difference of the alternate address and the pc after the single step. Afterward the Breakpoint returns the used address to the Proc so it can be used by other Tasks needing to do a single step out of line. The Proc maintains a single step out of line area pool of addresses that point to locations that are at least as big is the largest instruction of the instruction set. The Proc gets this list from the Isa the first time an address is requested through getOutOfLineAddress(). Currently this is (for x86 and x86_64) just the address of the main function entry point(see below). The address is taken out of the pool and the Breakpoint is responsible for putting it back through doneOutOfLine (see above). If no address is currently available the call blocks till one is available (this was way easier than inventing yet another TaskState and getting the communication between Proc and Task about this right, and contention is very low and at the longest it takes for an address to become available is one instruction single step). All the above seems to work nicely for x86 and x86_64 (powerpc hasn't been updated, but as long as an Isa doesn't return Instructions through an instruction parser that returns single stepping out of line capable Instructions the old reset-breakpoint stepping is used) with all the old testcases and a couple of new ones but there are 3 areas of improvement needed: - Instruction Parser. The framework is in place and works for the few Instructions that are known to the instruction parse, but there are all hand coded (see IA32InstructionParser which just handles NOP, INT3, RETQ and one JMP variant, the X8664Instruction just delegates to the IA32 for now). There don't seem to be libraries available to easily plugin that would give us the fixup instructions needed. The best available is the kprobes examples from the linux kernel which have as drawback that they are coded to be intimately tied to the kernel/C way of doing things and only handles instructions found in kernel space. For uprobes this should have been extended to handle every instruction that can occur in user space, but I haven't seen that work yet (and apparently is only available for x86 and no other architecture at this time). Any alternatives to look at would be appreciated. Otherwise I need to sit down with the various instruction manuals and just code it up by hand. (Bonus points for finding something that would not just give us ssol fixups but also simulation of instructions when hooked to the registers and memory of a Task). - Testsuite. The best I could come up with for now is TestInstructions and funit-instructions.c which is a nice little framework for having a simple assembly instructions labeled in such a way that a 'instruction address path' can be communicated to the java side so it can do either a full step through the program or install breakpoints on every instruction and make sure that every step and/or breakpoint hit takes it to the right next address. But the assembly part has to be written completely by hand (and unsurprisingly the simple assembly program currently used works identically on x86 and x86_64). Trying to reuse the funit-asm.h generic assembly instructions to make it platform neutral was really hard especially since the labels used on the C and inline assembly side have to kept in sync and mixing C defines and asm statements don't seem to mix very well. Also at the moment it is just using nops and jmps to keep things simple. I guess that in the end, if we have real instruction parsers we could try to generate them using that. Ideas or experiences with setting something up to track individual instructions and getting the right addresses listed appreciated. - Single Step Out Of Line Address Area. Currently the Isa (for x86 and x86_64 at least) just provide one address. The address of the main() function entry point taken by just doing: Elf elf = new Elf(proc.getExe(), ElfCommand.ELF_C_READ); Dwarf dwarf = new Dwarf(elf, DwarfCommand.READ, null); DwarfDie die = DwarfDie.getDecl(dwarf, "main"); return die.getEntryBreakpoints(); This works surprisingly well for a simple first approach, and programs generally don't reenter their own main() function. But it would be nice to either find an area that is guaranteed to never be used (again) by the process, or to map in an executable area in the inferior that is just used by us (maybe just making the inferior load a dummy shared library). Again any suggestions welcome. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ajocksch@redhat.com Wed Jul 4 19:13:00 2007 From: ajocksch@redhat.com (Adam Jocksch) Date: Wed, 04 Jul 2007 19:13:00 -0000 Subject: CountManager.java added Message-ID: <468BF13A.8030207@redhat.com> I've added frysk.rt.CountManager to the repository as a centralizaed place to get actionpoint identifiers. This is used by DisplayManager and I've modified BreakpointManager to use it as well. This is all in preparation for extending the hpd commands to displays From cagney@redhat.com Wed Jul 4 19:19:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 04 Jul 2007 19:19:00 -0000 Subject: What does brokenIfUtraceXXX() test for? In-Reply-To: <1183392408.3622.24.camel@dijkstra.wildebeest.org> References: <1183392408.3622.24.camel@dijkstra.wildebeest.org> Message-ID: <468BF2AF.9070704@redhat.com> See bug 3639. Seems fixing it slipped through the cracks, I fixed/closed the bug. 3489 contains a hidden references 3639 in one of the comments; I've also made that more obvious. As for brokenIfUtraceXXX, be careful to not read anything into it. The test has an unresolved problem, see BUG XXXXX :-) Mark Wielaard wrote: > Hi, > > I am seeing two failures on 2.6.21-1.3228.fc7 x86 SMP: > > testTerminateKillKILL(frysk.proc.TestTaskTerminateObserver)junit.framework.AssertionFailedError: terminating value expected:<-9> but was:<128> > testTerminatingKillKILL(frysk.proc.TestTaskTerminateObserver)junit.framework.AssertionFailedError: terminating value expected:<-9> but was:<128> > > That are guarded by brokenIfUtraceXXX() which has as explanation: > > /** > * A method that returns true, and prints broken, when the build > * kernel includes UTRACE. > */ > > So, tests guarded by that ever never expected to succeed with utrace > enabled? Or is it more subtle than that? Both bugs referenced through > these guards (#3525 and #3489) are closed already. > > Cheers, > > Mark > > From pmuldoon@redhat.com Thu Jul 5 04:21:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 05 Jul 2007 04:21:00 -0000 Subject: frysk-core/frysk/proc Breakpoint.java ChangeLo ... In-Reply-To: <20070702144017.21364.qmail@sourceware.org> References: <20070702144017.21364.qmail@sourceware.org> Message-ID: <468C71D3.2030409@redhat.com> mark@sourceware.org wrote: > Modified files: > frysk/proc : Breakpoint.java ChangeLog Isa.java IsaIA32.java > IsaPowerPC.java IsaX8664.java Proc.java > > Log message: > * Proc.java (outOfLineAddresses): New private final field. > (requestedOutOfLineAddresses): New boolean field. > (getOutOfLineAddress): New method. > (doneOutOfLine): Likewise. > > Mark, All this new stuff is very exciting. It is awesome to see! A minor nitpick if you will. I've not really looked at this code in a huge amount of detail, so please excuse my nativity here, but can't this code go and live in the live/LinuxProc.java implementation instead of the abstract Proc.java? The scope rules are package-private so they are not public apis? Other than keeping Proc.java as simple as possible, I'm not hugely worried. Regards Phil From pmuldoon@redhat.com Thu Jul 5 04:45:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 05 Jul 2007 04:45:00 -0000 Subject: Breakpoint stepping In-Reply-To: <1183573205.3598.157.camel@dijkstra.wildebeest.org> References: <1183573205.3598.157.camel@dijkstra.wildebeest.org> Message-ID: <468C7757.3050105@redhat.com> Mark Wielaard wrote: > > - Single Step Out Of Line Address Area. Currently the Isa (for x86 and > x86_64 at least) just provide one address. The address of the main() > function entry point taken by just doing: > > Elf elf = new Elf(proc.getExe(), ElfCommand.ELF_C_READ); > Dwarf dwarf = new Dwarf(elf, DwarfCommand.READ, null); > DwarfDie die = DwarfDie.getDecl(dwarf, "main"); > return die.getEntryBreakpoints(); > > This works surprisingly well for a simple first approach, and programs > generally don't reenter their own main() function. But it would be nice > to either find an area that is guaranteed to never be used (again) by > the process, or to map in an executable area in the inferior that is > just used by us (maybe just making the inferior load a dummy shared > library). Again any suggestions welcome. > Mark, I'm still reading the rest of your email (the state machine changes I'm still trying to understand). Is the above entry point code similar too getting the Entry Point from the process auxiliary? Something like: Auxv[] auxv = proc.getAuxv (); long entryPoint = 0; if (auxv == null) return 0; // Find the Auxv ENTRY data for (int i = 0; i < auxv.length; i++) if (auxv[i].type == inua.elf.AT.ENTRY) { entryPoint = auxv[i].val; break; } Not sure if one is more expensive than the other, just trivia really. As a side point, be sure to close to call elf.close() which immediately dispenses of the fd associated with the Elf object. It will eventually be cleaned up "anyway" on the finalize() call but that can happen quite a long time away. I agree on the main() entry-point being a good first step to as a usable space, though I wonder how that would look in a corefile. Though I suspect if you are dumping core while stepping a process one is in deeper trouble than one suspects ;) One of the other ideas was creating a custom solib and using it's address space to store the stuff needed. All this sounds hacky though. I vaguely recall a discussion to how uprobes does something similar by mapping in a page from somewhere? Do you remember any of that stuff? Regards Phil From mark@klomp.org Thu Jul 5 12:05:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Thu, 05 Jul 2007 12:05:00 -0000 Subject: frysk-core/frysk/proc Breakpoint.java ChangeLo ... In-Reply-To: <468C71D3.2030409@redhat.com> References: <20070702144017.21364.qmail@sourceware.org> <468C71D3.2030409@redhat.com> Message-ID: <1183637129.32586.16.camel@dijkstra.wildebeest.org> Hi Phil, On Wed, 2007-07-04 at 23:21 -0500, Phil Muldoon wrote: > A minor nitpick if you will. I've not really looked at this code in a > huge amount of detail, so please excuse my nativity here, but can't this > code go and live in the live/LinuxProc.java implementation instead of > the abstract Proc.java? The scope rules are package-private so they are > not public apis? Other than keeping Proc.java as simple as possible, I'm > not hugely worried. Yes it can. I have put it on my list to move. But since it is an implementation detail I want to keep it package private, so some other consumer classes (Breakpoint and dependencies) need to move with it and I don't want to make those unnecessary public and break the abstraction. I'll get to it after some other testing stuff. Thanks, Mark From mark@klomp.org Thu Jul 5 12:39:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Thu, 05 Jul 2007 12:39:00 -0000 Subject: Breakpoint stepping In-Reply-To: <468C7757.3050105@redhat.com> References: <1183573205.3598.157.camel@dijkstra.wildebeest.org> <468C7757.3050105@redhat.com> Message-ID: <1183639162.32586.24.camel@dijkstra.wildebeest.org> Hi Phil, On Wed, 2007-07-04 at 23:45 -0500, Phil Muldoon wrote: > I'm still reading the rest of your email (the state machine changes I'm > still trying to understand). Please ask, I might not explain them right, or maybe they are really not that clear/well done in the first place. > Is the above entry point code similar too getting the Entry Point from > the process auxiliary? Cool! That is so much easier than what I was doing. Thanks, I didn't even know the auxiliary vector of a proc contained the entry point. Tested on x86 and x86_64 (and also added to powerpc now, even though I cannot test it and powerpc would need some other fixes to fully support ssol) and it works like a charm. Much nicer than mucking through the Elf image by hand. 2007-07-05 Mark Wielaard IsaIA32.java (getOutOfLineAddresses): Use Auxv entry point. IsaPowerPC.java (getOutOfLineAddresses): Likewise. IsaX8664.java (getOutOfLineAddresses): Likewise. I have to post more code to the list I see. You triggered on actual code instead of all the explanation of what it is all supposed to do. It is probably time to introduce a frysk-patches list to discuss actual patches a bit more (clicking through on the commit list URLs and trying to figure out what/why a change was made is pretty hard). > I agree on the main() entry-point being a good first step to as a usable > space, though I wonder how that would look in a corefile. Isn't that what ElfPrAuxv represents? But it might be wrong to have this in the Isa in the first place. It is probably a property of the Proc, not of the Isa. When I cleanup the outOfLineAddresses storage that you pointed out in the previous review I'll try to move this at the same time. > Though I > suspect if you are dumping core while stepping a process one is in > deeper trouble than one suspects ;) I admit to not have thought of this scenario. That is indeed troublesome since some breakpoints might actually still be embedded in the Proc code memory while the kernel writes out the core file. Have to think about that. What scenarios are there for a process to dump core? And is there any way for us to intercept and quickly remove any changes we done to the code segments before that? > One of the other ideas was creating > a custom solib and using it's address space to store the stuff needed. > All this sounds hacky though. I vaguely recall a discussion to how > uprobes does something similar by mapping in a page from somewhere? Do > you remember any of that stuff? uprobes has the kernel to help. So they just allocate a whole new VM area. We would have to somehow trigger a dummy shared library load inside the inferior (and hope it doesn't interfere with anything the process is doing at the time). Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: auxv.patch Type: text/x-patch Size: 4960 bytes Desc: not available URL: From mark@klomp.org Thu Jul 5 13:13:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Thu, 05 Jul 2007 13:13:00 -0000 Subject: Many new test failures (execvp: Too many open files) Message-ID: <1183641175.32586.34.camel@dijkstra.wildebeest.org> Hi, On my Fedora 7 x86 machine (2.6.21-1.3228.fc7 SMP) I am suddenly seeing lots and lots of new test failures/errors. Lots mention "execvp: Too many open files", I am not seeing this on my x86_64 Fedora Core 6 setup. And they only started to massively fail today it seems (although on irc some people say they saw them already earlier this week). Anyone know what that is about? I also saw that at the same time there was a renaming of "broken" to "unresolved" for the TestCases. Is that a functional change or just a textual change? Maybe some tests were mislabeled in the process, so they suddenly started running on my system and before they didn't and so triggering this "execvp: Too many open files" now? Cheers, Mark From cagney@redhat.com Thu Jul 5 14:23:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 05 Jul 2007 14:23:00 -0000 Subject: Many new test failures (execvp: Too many open files) In-Reply-To: <1183641175.32586.34.camel@dijkstra.wildebeest.org> References: <1183641175.32586.34.camel@dijkstra.wildebeest.org> Message-ID: <468CFEE8.7050900@redhat.com> Mark Wielaard wrote: > Hi, > > On my Fedora 7 x86 machine (2.6.21-1.3228.fc7 SMP) I am suddenly seeing > lots and lots of new test failures/errors. Lots mention "execvp: Too > many open files", I am not seeing this on my x86_64 Fedora Core 6 setup. > And they only started to massively fail today it seems (although on irc > some people say they saw them already earlier this week). Anyone know > what that is about? > > I'm guessing this wasn't a scratch build. Bug 4742. > I also saw that at the same time there was a renaming of "broken" to > "unresolved" for the TestCases. Is that a functional change or just a > textual change? Maybe some tests were mislabeled in the process, so they > suddenly started running on my system and before they didn't and so > triggering this "execvp: Too many open files" now? > Two things to do in this situation are to review the changes you suspect could be problematic, and to scratch build before/after trees of the specific change showing it caused the breakage. Andrew > From cagney@redhat.com Thu Jul 5 14:26:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 05 Jul 2007 14:26:00 -0000 Subject: Fedora 7 build problems Message-ID: <468CFF84.7060703@redhat.com> Just a heads up. My first day using Fedora 7 had an interesting result :-) (I also had to commit a workaround to a second problem, bug 4741) -------------- next part -------------- An embedded message was scrubbed... From: "cagney at redhat dot com" Subject: [Bug general/4742] New: gcj generating empty dependency lists Date: 4 Jul 2007 21:51:59 -0000 Size: 3389 URL: From cagney@redhat.com Thu Jul 5 14:29:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 05 Jul 2007 14:29:00 -0000 Subject: Fedora Core 5 closed Message-ID: <468D003D.6020406@redhat.com> Just FYI, I've closed the Fedora Core 5 tracker, and largely removed the fc5 specific checks. Note however, this doesn't mean that we're free of the pre-utrace kernels. RHEL 4 and other non-utrace systems live on :-) From mark@klomp.org Thu Jul 5 15:14:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Thu, 05 Jul 2007 15:14:00 -0000 Subject: Many new test failures (execvp: Too many open files) In-Reply-To: <468CFEE8.7050900@redhat.com> References: <1183641175.32586.34.camel@dijkstra.wildebeest.org> <468CFEE8.7050900@redhat.com> Message-ID: <1183648429.32586.47.camel@dijkstra.wildebeest.org> On Thu, 2007-07-05 at 10:23 -0400, Andrew Cagney wrote: > Mark Wielaard wrote: > > On my Fedora 7 x86 machine (2.6.21-1.3228.fc7 SMP) I am suddenly seeing > > lots and lots of new test failures/errors. Lots mention "execvp: Too > > many open files", I am not seeing this on my x86_64 Fedora Core 6 setup. > > And they only started to massively fail today it seems (although on irc > > some people say they saw them already earlier this week). Anyone know > > what that is about? > > > I'm guessing this wasn't a scratch build. Of course it was a scratch build, otherwise I would not reported it :) I always do a scratch build when doing any cvs update because our build system doesn't seem very robust in the face of file deletion, addition or renaming. I wasn't even aware incremental build should work unless you only made changes to existing files. Is it supposed to? I always start my day with a cvs update and then a scratch build and get myself some breakfast :) > Bug 4742. Interesting, make sure you report that one upstream. I don't believe many, if any, other project rely on the dependency generation feature of gcj so they probably have not heard about that yet. > > I also saw that at the same time there was a renaming of "broken" to > > "unresolved" for the TestCases. Is that a functional change or just a > > textual change? Maybe some tests were mislabeled in the process, so they > > suddenly started running on my system and before they didn't and so > > triggering this "execvp: Too many open files" now? > > > Two things to do in this situation are to review the changes you suspect > could be problematic, and to scratch build before/after trees of the > specific change showing it caused the breakage. Could you explain why the changes were made and what they were supposed to do? That would help in reviewing the issue. Thanks, Mark From mark@klomp.org Thu Jul 5 15:15:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Thu, 05 Jul 2007 15:15:00 -0000 Subject: Fedora Core 5 closed In-Reply-To: <468D003D.6020406@redhat.com> References: <468D003D.6020406@redhat.com> Message-ID: <1183648521.32586.49.camel@dijkstra.wildebeest.org> On Thu, 2007-07-05 at 10:29 -0400, Andrew Cagney wrote: > Just FYI, I've closed the Fedora Core 5 tracker, and largely removed the > fc5 specific checks. Would it make sense to have maintainers for the various platforms we are interested in, then we can just ask whether someone wants to maintain such an old platform tracker bug. I am mainly interested in Fedora 6 (x86_64) and Fedora 7 (x86) so I could take those two till I upgrade for example. > Note however, this doesn't mean that we're free of the pre-utrace > kernels. RHEL 4 and other non-utrace systems live on :-) Does that really matter? utrace doesn't have a userspace interface except though ptrace. If there are any differences in behavior then they are probably bugs in the ptrace layer. Or is there something else to watch out for between ptrace/utrace enabled kernels? Cheers, Mark From cagney@redhat.com Thu Jul 5 15:52:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 05 Jul 2007 15:52:00 -0000 Subject: test case, exceptions, and tearDown In-Reply-To: <20070703230452.GA3786@ca-server1.us.oracle.com> References: <468AC518.8050101@redhat.com> <20070703230452.GA3786@ca-server1.us.oracle.com> Message-ID: <468D1395.8020700@redhat.com> Kris, You rase several interesting points; and as you note there are different schools of thought. Can you point me at the JUnit thread where you raised this issue? I'd be interested in reading the discussion. JUnit gives us a common framework, and a set of conventions, that is proving more than sufficient to our needs. The only real stumbling block we've encountered is that JUnit holds to Java's underlying assumption that you yoour test can be written-once and run-everywhere. Frysk, being system dependent, doesn't have that luxury and so needs ways to identify tests that can't work or have problems in specific circumstances; and for that we've kludged up a work-around that draws on POSIX and its definition of UNSUPPORTED and UNRESOLVED. Given the success we're seeing with developers adding JUnit tests, I consider this more than sufficient. Andrew Kris Van Hees wrote: > While I agree in principle with the things you quote below, and in > general with most of the junit FAQ (as I have for many years), I do also > believe that we shouldn't necessarily blindly follow whatever is stated > in the FAQ. I mean that in very generic terms: the purpose of having a > testsuite is to provide us with clear, consistent, and above all useful > results. > > One thing I have always had an issue with concerning junit is the > blending of ERROR and FAIL in junit 4. I believe that the distinction > between a failed test (assertions failed or expected failure mode (e.g. > exception) occcured) and a test execution that failed (unexpected event > caused the test to not complete as expected, i.e. something made it > impossible to make a correct PASS/FAIL determination). In that sense, I > do not think it to be wise to always take the strict rule of just > letting exceptions bubble up to the framework. To me, the most > important word in the FAQ about this topic is "unexpected". If there is > an exception that is known to validly occur in a failure scenario (it > makes the test fail to satisfy it assertions) then that should be > reflected in the result differently from an unexpected exception that > interferes with the test execution. > > There are obviously different schools of thought, but given that Frysk > is already using 2 testing frameworks that are set up to return results > that fall within the POSIX categories (as described in the dejagnu > documentation as reference - discussed in past months), it would make > sense that we make use of the full spectrum of result messages in a > meaningful way. > From cagney@redhat.com Thu Jul 5 16:09:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 05 Jul 2007 16:09:00 -0000 Subject: Fedora Core 5 closed In-Reply-To: <1183648521.32586.49.camel@dijkstra.wildebeest.org> References: <468D003D.6020406@redhat.com> <1183648521.32586.49.camel@dijkstra.wildebeest.org> Message-ID: <468D17CD.50404@redhat.com> Mark Wielaard wrote: > On Thu, 2007-07-05 at 10:29 -0400, Andrew Cagney wrote: > >> Just FYI, I've closed the Fedora Core 5 tracker, and largely removed the >> fc5 specific checks. >> > > Would it make sense to have maintainers for the various platforms we are > interested in, then we can just ask whether someone wants to maintain > such an old platform tracker bug. I am mainly interested in Fedora 6 > (x86_64) and Fedora 7 (x86) so I could take those two till I upgrade for > example. > There are distro specific packagers; but beyond that we should all be taking responsibility for the systems we use. > >> Note however, this doesn't mean that we're free of the pre-utrace >> kernels. RHEL 4 and other non-utrace systems live on :-) >> > > Does that really matter? utrace doesn't have a userspace interface > except though ptrace. If there are any differences in behavior then they > are probably bugs in the ptrace layer. Or is there something else to > watch out for between ptrace/utrace enabled kernels? > > Sometimes it is a bug, sometimes is is a question of interpretation. Cf KILL you recently asked about. Andrew From cagney@redhat.com Thu Jul 5 16:14:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 05 Jul 2007 16:14:00 -0000 Subject: Many new test failures (execvp: Too many open files) In-Reply-To: <1183648429.32586.47.camel@dijkstra.wildebeest.org> References: <1183641175.32586.34.camel@dijkstra.wildebeest.org> <468CFEE8.7050900@redhat.com> <1183648429.32586.47.camel@dijkstra.wildebeest.org> Message-ID: <468D18E2.3080700@redhat.com> Mark Wielaard wrote: > On Thu, 2007-07-05 at 10:23 -0400, Andrew Cagney wrote: > >> Mark Wielaard wrote: >> >>> On my Fedora 7 x86 machine (2.6.21-1.3228.fc7 SMP) I am suddenly seeing >>> lots and lots of new test failures/errors. Lots mention "execvp: Too >>> many open files", I am not seeing this on my x86_64 Fedora Core 6 setup. >>> And they only started to massively fail today it seems (although on irc >>> some people say they saw them already earlier this week). Anyone know >>> what that is about? >>> >>> >> I'm guessing this wasn't a scratch build. >> > > Of course it was a scratch build, otherwise I would not reported it :) > I always do a scratch build when doing any cvs update because our build > system doesn't seem very robust in the face of file deletion, addition > or renaming. I wasn't even aware incremental build should work unless > you only made changes to existing files. Is it supposed to? > I always start my day with a cvs update and then a scratch build and get > myself some breakfast :) > > >> Bug 4742. >> > > Interesting, make sure you report that one upstream. I don't believe > many, if any, other project rely on the dependency generation feature of > gcj so they probably have not heard about that yet. > > >>> I also saw that at the same time there was a renaming of "broken" to >>> "unresolved" for the TestCases. Is that a functional change or just a >>> textual change? Maybe some tests were mislabeled in the process, so they >>> suddenly started running on my system and before they didn't and so >>> triggering this "execvp: Too many open files" now? >>> >>> >> Two things to do in this situation are to review the changes you suspect >> could be problematic, and to scratch build before/after trees of the >> specific change showing it caused the breakage. >> > > Could you explain why the changes were made and what they were supposed > to do? That would help in reviewing the issue. > You described it; s/brokenXXX/unresolvedOnYYY/ ; this finishes the introduction of UNRESOLVED I started some time ago. You'll also see I killed some unused functions; and simplified unresolvedOnUtrace (as fc5 is gone). Perhaps it is that last change? Andrew From kris.van.hees@oracle.com Thu Jul 5 16:28:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Thu, 05 Jul 2007 16:28:00 -0000 Subject: test case, exceptions, and tearDown In-Reply-To: <468D1395.8020700@redhat.com> References: <468AC518.8050101@redhat.com> <20070703230452.GA3786@ca-server1.us.oracle.com> <468D1395.8020700@redhat.com> Message-ID: <20070705162752.GG3786@ca-server1.us.oracle.com> I have not raised these issues in any JUnit thrad, nor do I believe there is much point in doing so. The JUnit developers have stated their opinion rather strongly on these issues, and I honestly do not believe they are open to changing their mind on this. I had numerous conversations without organizations about this topic, and the feelings on both sides of the issue seem to be rather strong. Sorry that there has not been a more public discussion about this, that I am aware of. If a lack of distinction between a test failing due to external influences (or being non-deterministic) and a recognized exception triggering a failure is acceptable, the suggested use of junit is of course sufficient. Given our situation (needing to deal with more system specific details), and as you say not being able to depend on a write-one-run-anywhere situation, I don't think we can simply stick to the overall recommendations by the junit team. After all, we are *not* working within their ideal environment. Anyway, given that there are clearly two positions on this topic, majority opinion ought to drive the final decision. If we are to go with a folding of ERROR and FAIL, I do want to suggest though that failing tests are given more attention in view of such failure potentially being a result of a true problem with the test itself rather than a reflection of the implemented assertions not passing. Cheers, Kris On Thu, Jul 05, 2007 at 11:51:49AM -0400, Andrew Cagney wrote: > Kris, > > You rase several interesting points; and as you note there are different > schools of thought. Can you point me at the JUnit thread where you > raised this issue? I'd be interested in reading the discussion. > > JUnit gives us a common framework, and a set of conventions, that is > proving more than sufficient to our needs. The only real stumbling > block we've encountered is that JUnit holds to Java's underlying > assumption that you yoour test can be written-once and run-everywhere. > Frysk, being system dependent, doesn't have that luxury and so needs > ways to identify tests that can't work or have problems in specific > circumstances; and for that we've kludged up a work-around that draws on > POSIX and its definition of UNSUPPORTED and UNRESOLVED. > > Given the success we're seeing with developers adding JUnit tests, I > consider this more than sufficient. > > Andrew > > > Kris Van Hees wrote: > >While I agree in principle with the things you quote below, and in > >general with most of the junit FAQ (as I have for many years), I do also > >believe that we shouldn't necessarily blindly follow whatever is stated > >in the FAQ. I mean that in very generic terms: the purpose of having a > >testsuite is to provide us with clear, consistent, and above all useful > >results. > > > >One thing I have always had an issue with concerning junit is the > >blending of ERROR and FAIL in junit 4. I believe that the distinction > >between a failed test (assertions failed or expected failure mode (e.g. > >exception) occcured) and a test execution that failed (unexpected event > >caused the test to not complete as expected, i.e. something made it > >impossible to make a correct PASS/FAIL determination). In that sense, I > >do not think it to be wise to always take the strict rule of just > >letting exceptions bubble up to the framework. To me, the most > >important word in the FAQ about this topic is "unexpected". If there is > >an exception that is known to validly occur in a failure scenario (it > >makes the test fail to satisfy it assertions) then that should be > >reflected in the result differently from an unexpected exception that > >interferes with the test execution. > > > >There are obviously different schools of thought, but given that Frysk > >is already using 2 testing frameworks that are set up to return results > >that fall within the POSIX categories (as described in the dejagnu > >documentation as reference - discussed in past months), it would make > >sense that we make use of the full spectrum of result messages in a > >meaningful way. > > > From mark@klomp.org Thu Jul 5 17:00:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Thu, 05 Jul 2007 17:00:00 -0000 Subject: Many new test failures (execvp: Too many open files) In-Reply-To: <468D18E2.3080700@redhat.com> References: <1183641175.32586.34.camel@dijkstra.wildebeest.org> <468CFEE8.7050900@redhat.com> <1183648429.32586.47.camel@dijkstra.wildebeest.org> <468D18E2.3080700@redhat.com> Message-ID: <1183654836.32586.73.camel@dijkstra.wildebeest.org> Hi Andrew, On Thu, 2007-07-05 at 12:14 -0400, Andrew Cagney wrote: > > Could you explain why the changes were made and what they were supposed > > to do? That would help in reviewing the issue. > > > You described it; s/brokenXXX/unresolvedOnYYY/ ; this finishes the > introduction of UNRESOLVED I started some time ago. OK, I must have missed that sorry. So there is not supposed to be any functional change just a global search/replace on the whole code base because unresolved is a better term than broken? > You'll also see I > killed some unused functions; and simplified unresolvedOnUtrace (as fc5 > is gone). Perhaps it is that last change? I'll try that out tomorrow morning. On irc we discussed the problem of leaking file descriptors in things like Elf objects which currently seem to rely on garbage collection to close out unused descriptors. So it might also be some subtle change in memory use that make the garbage collector trigger earlier or later. In that case it is probably that we just fail to close()/destroy() the right object at the right time. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cagney@redhat.com Thu Jul 5 18:03:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 05 Jul 2007 18:03:00 -0000 Subject: Many new test failures (execvp: Too many open files) In-Reply-To: <1183654836.32586.73.camel@dijkstra.wildebeest.org> References: <1183641175.32586.34.camel@dijkstra.wildebeest.org> <468CFEE8.7050900@redhat.com> <1183648429.32586.47.camel@dijkstra.wildebeest.org> <468D18E2.3080700@redhat.com> <1183654836.32586.73.camel@dijkstra.wildebeest.org> Message-ID: <468D3251.9010808@redhat.com> Mark Wielaard wrote: > I'll try that out tomorrow morning. On irc we discussed the problem of > leaking file descriptors in things like Elf objects which currently seem > to rely on garbage collection to close out unused descriptors. So it > might also be some subtle change in memory use that make the garbage > collector trigger earlier or later. In that case it is probably that we > just fail to close()/destroy() the right object at the right time. > Thanks. From cagney@redhat.com Thu Jul 5 18:04:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 05 Jul 2007 18:04:00 -0000 Subject: test case, exceptions, and tearDown In-Reply-To: <20070705162752.GG3786@ca-server1.us.oracle.com> References: <468AC518.8050101@redhat.com> <20070703230452.GA3786@ca-server1.us.oracle.com> <468D1395.8020700@redhat.com> <20070705162752.GG3786@ca-server1.us.oracle.com> Message-ID: <468D32B4.9020701@redhat.com> Kris Van Hees wrote: > Anyway, given that there are clearly two positions on this topic, > majority opinion ought to drive the final decision. If we are to go > with a folding of ERROR and FAIL, I do want to suggest though that > failing tests are given more attention in view of such failure > potentially being a result of a true problem with the test itself rather > than a reflection of the implemented assertions not passing. > To true; for my part I've already closed out two Fedora 7 failures. Andrew From cagney@redhat.com Thu Jul 5 18:37:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 05 Jul 2007 18:37:00 -0000 Subject: Breakpoint stepping In-Reply-To: <1183573205.3598.157.camel@dijkstra.wildebeest.org> References: <1183573205.3598.157.camel@dijkstra.wildebeest.org> Message-ID: <468D3A87.4020205@redhat.com> Mark, Can I suggest adding this, or something based on it, to frysk.proc.live.package.html? It's this useful! information we should be accumulating in the source tree. Andrew Mark Wielaard wrote: > As you might have noticed over the last week I have dropped in the new > breakpoint stepping framework (or hopefully you didn't notice since I > did try to do it in chunks that all had no detectable functional > behavior changes). This is an update to my previous general stepping > overview http://sourceware.org/ml/frysk/2007-q2/msg00283.html > and a request for review of the next steps with regard to the > instruction parsers, testframework and what to use as ssol area. > > The main difference with the previous stepping overview regarding the > ptrace state machine is that there is now an explicit Stepping state, > which is a sub-state of Running and that Running.sendContinue() now not > only determines how to instruct ptrace to continue the task, but also > returns a different Running state based on whether or not we asked for a > continue or step-continue. This makes interpreting the cause of the trap > event we subsequently expect to get easier. This was previously recorded > as a field in the Task itself. > > With respect to breakpoints the ptrace task states have been adapted to > all call setupSteppingBreakpoint() after a breakpoint hit has been > detected, which makes sure the PC is setup correctly (which previously > could be off by one on some architectures) and to mark the Task as being > at that particular breakpoint (this is still kept as Task field for now) > and to not actually call Breakpoint.prepareStep(), which is now handled > in Running.sendContinue(). In the previous version when reset-breakpoint > stepping was used another task could miss the breakpoint if the Task > moved into a Blocked state before continuing. > > All the logic of how to breakpoint step has been moved into the > Breakpoint class that checks the properties of a new Instruction class > object which is created by the Isa through an instruction parser before > the breakpoint is inserted at a given location (previously we > represented instructions just as a byte[]). An Instruction knows how > long the instruction is, which bytes it represents, whether it can be > single stepped out of line and how to set that up given the original pc > location and an alternative address, plus any fixups that are needed to > the Task afterwards (and it has a notion of whether or not the > Instruction can be simulated, but that isn't currently used, see below). > A Breakpoint ties an Instruction to a particular address and Proc (and > Tasks can have zero or more Breakpoints, they share the same Breakpoint > on the same address with other Tasks of a Proc and when no Tasks of a > Proc has an Breakpoint at a particular address anymore the Breakpoint is > removed). > > For stepping the Breakpoint the Running.sendContinue() method first > calls Breakpoint.prepareStep(), then signals ptrace to do a single step > of the Task, putting the Task in Stepping state and then in > handleTrapEvent() calls Breakpoint.stepDone(). prepareStep() queries the > capabilities of the Instruction at the pc address and depending on that > either sets things up for doing a step out of line, simulate the > instruction (but none of the current Instructions have been setup to do > simulation yes, and look at the comment in prepareStep() to see what is > needed to fully enable this option) or reset the current Instruction > (removing the breakpoint instruction temporarily). Accordingly a > Breakpoint can be in the state NOT_STEPPING, OUT_OF_LINE_STEPPING, > SIMULATE_STEPPING or RESET_STEPPING. > > In the case of RESET_STEPPING (which was the only option we supported > before) other Tasks might miss and just past the Breakpoint during the > brief period between the reset, step and reinstall. Breakpoint > prepareStep() just takes the Instruction bytes and puts them at the > current pc address, and doneStep() reinstates the breakpoint > instruction. > > When the Instruction supports single step out of line then the > Breakpoint requests an address in the single step out of line area of > the Proc, instructs the Instruction to install itself there for the > current Task calling Instruction.setupExecuteOutOfLine(). The default > action of setupExecuteOutOfLine() is to set the pc to the given address > and place a copy the instruction bytes there (although this can be > overridden if an Instruction wants to do something more fancy). When the > task signals the Breakpoint that a step was taken by calling stepDone(), > the Breakpoint calls Instruction fixupExecuteOutOfLine() with the > original pc and replacement address so any adjustments can be done to > the Task registers. The default action is to just set the pc to the > original pc plus the length of the Instruction just stepped. But > Instructions can override that if more is needed. As an example the RET > instruction doesn't do any fixup (since the only action is setting the > pc to the right location in the first place) and the JMP instruction > sets the pc to original pc plus/minus the difference of the alternate > address and the pc after the single step. Afterward the Breakpoint > returns the used address to the Proc so it can be used by other Tasks > needing to do a single step out of line. > > The Proc maintains a single step out of line area pool of addresses that > point to locations that are at least as big is the largest instruction > of the instruction set. The Proc gets this list from the Isa the first > time an address is requested through getOutOfLineAddress(). Currently > this is (for x86 and x86_64) just the address of the main function entry > point(see below). The address is taken out of the pool and the > Breakpoint is responsible for putting it back through doneOutOfLine (see > above). If no address is currently available the call blocks till one is > available (this was way easier than inventing yet another TaskState and > getting the communication between Proc and Task about this right, and > contention is very low and at the longest it takes for an address to > become available is one instruction single step). > > All the above seems to work nicely for x86 and x86_64 (powerpc hasn't > been updated, but as long as an Isa doesn't return Instructions through > an instruction parser that returns single stepping out of line capable > Instructions the old reset-breakpoint stepping is used) with all the old > testcases and a couple of new ones but there are 3 areas of improvement > needed: > > - Instruction Parser. The framework is in place and works for the few > Instructions that are known to the instruction parse, but there are all > hand coded (see IA32InstructionParser which just handles NOP, INT3, RETQ > and one JMP variant, the X8664Instruction just delegates to the IA32 for > now). There don't seem to be libraries available to easily plugin that > would give us the fixup instructions needed. The best available is the > kprobes examples from the linux kernel which have as drawback that they > are coded to be intimately tied to the kernel/C way of doing things and > only handles instructions found in kernel space. For uprobes this should > have been extended to handle every instruction that can occur in user > space, but I haven't seen that work yet (and apparently is only > available for x86 and no other architecture at this time). Any > alternatives to look at would be appreciated. Otherwise I need to sit > down with the various instruction manuals and just code it up by hand. > (Bonus points for finding something that would not just give us ssol > fixups but also simulation of instructions when hooked to the registers > and memory of a Task). > > - Testsuite. The best I could come up with for now is TestInstructions > and funit-instructions.c which is a nice little framework for having a > simple assembly instructions labeled in such a way that a 'instruction > address path' can be communicated to the java side so it can do either a > full step through the program or install breakpoints on every > instruction and make sure that every step and/or breakpoint hit takes it > to the right next address. But the assembly part has to be written > completely by hand (and unsurprisingly the simple assembly program > currently used works identically on x86 and x86_64). Trying to reuse the > funit-asm.h generic assembly instructions to make it platform neutral > was really hard especially since the labels used on the C and inline > assembly side have to kept in sync and mixing C defines and asm > statements don't seem to mix very well. Also at the moment it is just > using nops and jmps to keep things simple. I guess that in the end, if > we have real instruction parsers we could try to generate them using > that. Ideas or experiences with setting something up to track individual > instructions and getting the right addresses listed appreciated. > > - Single Step Out Of Line Address Area. Currently the Isa (for x86 and > x86_64 at least) just provide one address. The address of the main() > function entry point taken by just doing: > > Elf elf = new Elf(proc.getExe(), ElfCommand.ELF_C_READ); > Dwarf dwarf = new Dwarf(elf, DwarfCommand.READ, null); > DwarfDie die = DwarfDie.getDecl(dwarf, "main"); > return die.getEntryBreakpoints(); > > This works surprisingly well for a simple first approach, and programs > generally don't reenter their own main() function. But it would be nice > to either find an area that is guaranteed to never be used (again) by > the process, or to map in an executable area in the inferior that is > just used by us (maybe just making the inferior load a dummy shared > library). Again any suggestions welcome. > From cagney@redhat.com Thu Jul 5 18:43:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 05 Jul 2007 18:43:00 -0000 Subject: inner classes with fields names similar to outer class/method fields In-Reply-To: <1183379510.3622.17.camel@dijkstra.wildebeest.org> References: <1183379510.3622.17.camel@dijkstra.wildebeest.org> Message-ID: <468D3BC0.3070501@redhat.com> There are two postscripts to this thread: - in looking at rewriting TaskEvent to eliminate the global variable issue I found that the below shouldn't even be using TaskEvent; instead it should use frysk.event.Event - this code is susceptible to bug 4282 :-( Mark Wielaard wrote: > Manager.eventLoop.add(new TaskEvent() > { > public void execute () > { > // Continue running (inside syscall), > // while attaching another syscall observer > - task.requestUnblock(syso); > - task.requestAddSyscallObserver(syso2); > + proc_task.requestUnblock(syso); > + proc_task.requestAddSyscallObserver(syso2); > } > }); > > > From cagney@redhat.com Thu Jul 5 21:05:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 05 Jul 2007 21:05:00 -0000 Subject: frysk.rt.SteppingEngine poking at a task's blocker list? Message-ID: <468D5D0C.10505@redhat.com> Tim, Mike, I noticed this in frysk.rt.SteppingEngine: /** * Unblock a task so that, from the point of view of the stepping * engine, execution can continue. For now this unblocks * instruction observers and code observers for breakpoints, but * ultimately I (timoore) think it should unblock all blockers. */ public boolean continueForStepping(Task task, boolean unblockStepper) { if (unblockStepper) { task.requestUnblock(this.steppingObserver); } TaskObserver[] blockers = (TaskObserver [])task.getBlockers().clone(); for (int j = 0; j < blockers.length; j++) { // One of ours? if (blockers[j] instanceof Breakpoint) { task.requestUnblock(blockers[j]); } else { // Some blocker that we don't know about // System.out.println("Unknown blocker " + blockers[j].toString()); // return false; } } return true; } I'm not sure what is happening here, but the underlying code should operate as: -> process hits a breakpoint instruction -> all low-level CodeObservers fire -> all corresponding high-level Breakpoint observers fire -> Breakpoint observers each notify Stepping engine to stop (accompanied by corresponding low-level CodeObserver doing the block) This will leave the SteppingEngine with a full list of CodeObservers to unblock without needing to poke around an assumed live task's internal state. The flexibility of this approach also lets us write custom high-level breakpoint observers, in the monitor say, that can be implemented using just the Breakpoint and its shared-library Manager, and not have to worry about the stepping engine at all. Andrew PS: And it prevents me moving this blockers stuff into frysk.proc.live :-( :-) From timoore@redhat.com Fri Jul 6 14:04:00 2007 From: timoore@redhat.com (Tim Moore) Date: Fri, 06 Jul 2007 14:04:00 -0000 Subject: frysk.rt.SteppingEngine poking at a task's blocker list? In-Reply-To: <468D5D0C.10505@redhat.com> References: <468D5D0C.10505@redhat.com> Message-ID: <468E4BFB.5010604@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Cagney wrote: > Tim, Mike, > > I noticed this in frysk.rt.SteppingEngine: > > /** > * Unblock a task so that, from the point of view of the stepping > * engine, execution can continue. For now this unblocks > * instruction observers and code observers for breakpoints, but > * ultimately I (timoore) think it should unblock all blockers. > */ > public boolean continueForStepping(Task task, boolean unblockStepper) { > if (unblockStepper) { > task.requestUnblock(this.steppingObserver); > } > TaskObserver[] blockers = (TaskObserver > [])task.getBlockers().clone(); > for (int j = 0; j < blockers.length; j++) { > // One of ours? > if (blockers[j] instanceof Breakpoint) { > task.requestUnblock(blockers[j]); > } else { > // Some blocker that we don't know about > // System.out.println("Unknown blocker " + > blockers[j].toString()); > // return false; > } > } > return true; > } > > I'm not sure what is happening here, but the underlying code should > operate as: > -> process hits a breakpoint instruction > -> all low-level CodeObservers fire > -> all corresponding high-level Breakpoint observers fire > -> Breakpoint observers each notify Stepping engine to stop (accompanied > by corresponding low-level CodeObserver doing the block) > This will leave the SteppingEngine with a full list of CodeObservers to > unblock without needing to poke around an assumed live task's internal > state. I was going on the theory that it would be better to not have to interact with the stepping engine when setting breakpoints. I see below that you're after the same thing, which we talked about, so I'm surprised that you want breakpoints to depend on the stepping engine at all. > > The flexibility of this approach also lets us write custom high-level > breakpoint observers, in the monitor say, that can be implemented using > just the Breakpoint and its shared-library Manager, and not have to > worry about the stepping engine at all. > Should the stepping engine be able to step from/over any blocker, or only breakpoints? Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGjkv6eDhWHdXrDRURAhfuAKDLORozDZHVWTXVmOvpjSYL+M+yIwCbBLmC PsaU/RBoxyjCp2LrolM0Y2k= =iBrX -----END PGP SIGNATURE----- From mcvet@redhat.com Fri Jul 6 14:25:00 2007 From: mcvet@redhat.com (Mike Cvet) Date: Fri, 06 Jul 2007 14:25:00 -0000 Subject: frysk.rt.SteppingEngine poking at a task's blocker list? In-Reply-To: <468E4BFB.5010604@redhat.com> References: <468D5D0C.10505@redhat.com> <468E4BFB.5010604@redhat.com> Message-ID: <468E50B9.6050606@redhat.com> Tim Moore wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Andrew Cagney wrote: > >> Tim, Mike, >> >> I noticed this in frysk.rt.SteppingEngine: >> >> /** >> * Unblock a task so that, from the point of view of the stepping >> * engine, execution can continue. For now this unblocks >> * instruction observers and code observers for breakpoints, but >> * ultimately I (timoore) think it should unblock all blockers. >> */ >> public boolean continueForStepping(Task task, boolean unblockStepper) { >> if (unblockStepper) { >> task.requestUnblock(this.steppingObserver); >> } >> TaskObserver[] blockers = (TaskObserver >> [])task.getBlockers().clone(); >> for (int j = 0; j < blockers.length; j++) { >> // One of ours? >> if (blockers[j] instanceof Breakpoint) { >> task.requestUnblock(blockers[j]); >> } else { >> // Some blocker that we don't know about >> // System.out.println("Unknown blocker " + >> blockers[j].toString()); >> // return false; >> } >> } >> return true; >> } >> >> I'm not sure what is happening here, but the underlying code should >> operate as: >> -> process hits a breakpoint instruction >> -> all low-level CodeObservers fire >> -> all corresponding high-level Breakpoint observers fire >> -> Breakpoint observers each notify Stepping engine to stop (accompanied >> by corresponding low-level CodeObserver doing the block) >> This will leave the SteppingEngine with a full list of CodeObservers to >> unblock without needing to poke around an assumed live task's internal >> state. >> > I was going on the theory that it would be better to not have to > interact with the stepping engine when setting breakpoints. I see below > that you're after the same thing, which we talked about, so I'm > surprised that you want breakpoints to depend on the stepping engine at all. > > I believe it would be best for the SteppingEngine to have some sort of Observer which is notified upon any breakpoint events relevent to the Task at hand, and deal appropriately with the situation then, instead of trying to run through that potential blockers list each time. So any time a breakpoint is set anywhere, or removed anywhere, it updates that Observer in the SteppingEngine. From mark@klomp.org Fri Jul 6 15:02:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Fri, 06 Jul 2007 15:02:00 -0000 Subject: [patch] Check for SYSCALL on x86_64 after "spurious" step/trap Message-ID: <1183734114.3651.82.camel@dijkstra.wildebeest.org> Hi, On some x86_64 kernels you will get a trapped event after a step out of a syscall, but the stepping flag isn't set in that case. This is at least the case at least on 2.6.18-8.1.6.el5, but not on any of the Fedora kernels I ever tested with, currently 2.6.20-1.2962.fc6. Luckily the Isa has a way to signal such an event and this patch updates the X86_64 Isa as follows to handle this: 2007-07-06 Mark Wielaard * IsaX8664.java hasExecutedSpuriousTrap): Check for SYSCALL instruction. This makes the following testcases PASS on such kernels and doesn't change the results on any other system I tested on: testSteppingtestHitAndRun(frysk.proc.TestBreakpoints) ...PASS testSteppingtestInsertRemove(frysk.proc.TestBreakpoints) ...PASS testSteppingAddLots(frysk.proc.TestBreakpoints) ...PASS testStepSigReturn(frysk.proc.TestTaskObserverInstructionSigReturn) ...PASS Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: isa-update.patch Type: text/x-patch Size: 1031 bytes Desc: URL: From mark@klomp.org Fri Jul 6 15:39:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Fri, 06 Jul 2007 15:39:00 -0000 Subject: libgcj update troubles on fc6 In-Reply-To: <1183457192.3599.25.camel@dijkstra.wildebeest.org> References: <1183457192.3599.25.camel@dijkstra.wildebeest.org> Message-ID: <1183736361.3651.84.camel@dijkstra.wildebeest.org> On Tue, 2007-07-03 at 12:06 +0200, Mark Wielaard wrote: > Seeing there was an updated package for gcc on my FC6 machine I happily > let the thing update itself. However libgcj breaks while updating: OK, this seems to be just me. I got 2 people reporting the update worked fine for them. I don't know what or why things went wrong for me though :{ Cheers, Mark From cagney@redhat.com Fri Jul 6 19:38:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 06 Jul 2007 19:38:00 -0000 Subject: frysk.rt.SteppingEngine poking at a task's blocker list? In-Reply-To: <468E4BFB.5010604@redhat.com> References: <468D5D0C.10505@redhat.com> <468E4BFB.5010604@redhat.com> Message-ID: <468E9A23.7060806@redhat.com> Tim Moore wrote: >> I'm not sure what is happening here, but the underlying code should >> operate as: >> -> process hits a breakpoint instruction >> -> all low-level CodeObservers fire >> -> all corresponding high-level Breakpoint observers fire >> -> Breakpoint observers each notify Stepping engine to stop (accompanied >> by corresponding low-level CodeObserver doing the block) >> This will leave the SteppingEngine with a full list of CodeObservers to >> unblock without needing to poke around an assumed live task's internal >> state. >> > I was going on the theory that it would be better to not have to > interact with the stepping engine when setting breakpoints. I see below > that you're after the same thing, which we talked about, so I'm > surprised that you want breakpoints to depend on the stepping engine at all. > > That's the right approach; it just needs to be taken a little bit further: -> low-level CodeObserver, implemented by frysk.proc -> the high-level Breakpoint, as you've implemented, sub-classes providing ElfBreakpoints, File/Line breakpoints, DebugInfoBreakpoint and so on => the monitor can use these, as can code implementing ltrace => tests such as for the Display can also use those low-level breakpoints without getting involved with => in the case of the hpd and/or debug-window >> The flexibility of this approach also lets us write custom high-level >> breakpoint observers, in the monitor say, that can be implemented using >> just the Breakpoint and its shared-library Manager, and not have to >> worry about the stepping engine at all. >> >> > > Should the stepping engine be able to step from/over any blocker, or > only breakpoints? > Only user level breakpoints; other components, such as a monitor logger breakpoint, are not visible. This is all heavily reliant on the underlying .proc code consistently reporting breakpoints so that they can also be handled by the state machine; for instance: => step onto a breakpoint The breakpoint fires (even though it hasn't actually executed) and notifies the stepper that it is blocking the thread. The next step unblocks that breakpoint and re-steps => step-over over a function that has a breakpoint => step-over a line containing an embedded breakpoint The breakpoint causes the stepping engine to stop (but an option to override this would be nice); the main thing is that the user breakpoint notifies the stepping engine so that the stepping engine can make a decision. Andrew From cagney@redhat.com Fri Jul 6 21:43:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 06 Jul 2007 21:43:00 -0000 Subject: frysk-core/frysk/proc ChangeLog IsaIA32.java I ... In-Reply-To: <46829FE9.8030402@redhat.com> References: <20070626221253.13799.qmail@sourceware.org> <1182934638.1046.26.camel@dijkstra.wildebeest.org> <468266E7.70707@redhat.com> <46827A9D.70300@redhat.com> <1182964334.3636.25.camel@dijkstra.wildebeest.org> <46829FE9.8030402@redhat.com> Message-ID: <468EB796.5040903@redhat.com> Phil Muldoon wrote: > Moving forward, here is something I have been thinking about. As > Host/Proc/Task.java are basically "contracts" of how a Host/Proc/Task > should be modeled on any system, they should in fact be straight > interfaces, not abstract classes. This achieves two things: > > 1) Stops code being placed in Host/Proc/Task that really should not be > there, but in some concrete class (implementor). > 2) Just defines the structure of a Host/Proc/Task without placing any > expectations on its implementation. Implementation details should not > be a concept at this level. > > Furthermore the whole concept of a state machine should be moved > entirely to the implementing classes. I'm not sure how this will scale > throughout the frysk model, but a state machine is fake for a corefile > proc. It has no state, it's stone-cold dead. It will never live again > (I'm ignoring the fact that someday someone might try to resurrect the > process in its state just before it died). It will never spawn or lose > tasks. > > I'll take a radical view here and say the proc/ namespace is too busy. > In fact, I think the proc/ model should just have: > > - Interfaces > > - sub-packages like dead/ and live/ that implement the interfaces. In > those sub-packages should be all the ByteBuffer details that should be > entirely package private to stop instantiation of process specific > ByteBuffers. All tests, and so on. > Yes, exactly; much of what is in Task, and Proc should be booted down a level; mostly to frysk.proc.live.LiveTask. > It's a germ of an idea at the moment, but something I've warmed too > over the weeks I've been thinking on it. > > Regards > > Phil > From mark@klomp.org Sat Jul 7 13:30:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Sat, 07 Jul 2007 13:30:00 -0000 Subject: Mixing syscalls and breakpoints at the command line Message-ID: <1183815029.3718.67.camel@dijkstra.wildebeest.org> Hi, The following thread on gdb-patches is interesting: http://thread.gmane.org/gmane.comp.gdb.patches/34421 It shows a way for mixing syscalls and breakpoints as if they were the same kind of thing on the command line. Maybe something we should also support in the fhpd. And I think we can do better with the argument printing than in the example below and of course with a way to select a specific syscall, preferably by name since we already have that info [1]. I don't know whether or not the hpd spec has anything to say about intercepting syscalls. I couldn't find anything in a quick scan. Cheers, Mark [1] From the first email in that thread: gdb) catch syscall Catchpoint 1 (syscall) (gdb) r (no debugging symbols found) # we've stopped at entry to the first syscall. Catchpoint 1 (syscall), 0x1000008c in _start () # on linuxppc where I'm testing, register r0 holds the syscall number (gdb) p $r0 # 4 is __NR_write $1 = 4 # The arguments to the syscall are in registers r3, r4, r5, etc. (gdb) p $r3 # writing to fd 1, stdout $2 = 1 (gdb) x/s $r4 0x10000098: "hello world\n" (gdb) p $r5 # strlen("hello world\n") is 12 $3 = 12 # Continuing from here allows the syscall to complete, then stops again (gdb) c hello world # Notice the PC didn't change, we're still at 0x1000008c Catchpoint 1 (syscall), 0x1000008c in _start () # Now continue again, until the next syscall (gdb) c Catchpoint 1 (syscall), 0x10000098 in ?? () (gdb) p $r0 # 1 is __NR_exit $4 = 1 (gdb) p $r3 $5 = 0 (gdb) c -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Mon Jul 9 08:18:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 09 Jul 2007 08:18:00 -0000 Subject: [patch] Breakpoint - only reset instruction bytes covered by breakpoint instruction bytes Message-ID: <1183969101.3654.5.camel@dijkstra.wildebeest.org> Hi, This is kind of an micro optimization. But it was noticable during a trace while investigating breakpoint set/reset behavior. And potentially setting bytes in the inferior is expensive. So here is a little patchlet to not do any unnecessary work while resetting (or uninstalling) a breakpoint. 2007-07-09 Mark Wielaard * Breakpoint.java (reset): Only copy back bytes covered by breakpiont instructions. Tested on x86_64/FC6, no regressions. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: Breakpoint.patch Type: text/x-patch Size: 1034 bytes Desc: not available URL: From mark@klomp.org Mon Jul 9 09:25:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 09 Jul 2007 09:25:00 -0000 Subject: Many new test failures (execvp: Too many open files) In-Reply-To: <468D18E2.3080700@redhat.com> References: <1183641175.32586.34.camel@dijkstra.wildebeest.org> <468CFEE8.7050900@redhat.com> <1183648429.32586.47.camel@dijkstra.wildebeest.org> <468D18E2.3080700@redhat.com> Message-ID: <1183973147.3654.23.camel@dijkstra.wildebeest.org> Hi Andrew, On Thu, 2007-07-05 at 12:14 -0400, Andrew Cagney wrote: > Mark Wielaard wrote: > > Could you explain why the changes were made and what they were supposed > > to do? That would help in reviewing the issue. > > > You described it; s/brokenXXX/unresolvedOnYYY/ ; this finishes the > introduction of UNRESOLVED I started some time ago. You'll also see I > killed some unused functions; and simplified unresolvedOnUtrace (as fc5 > is gone). Perhaps it is that last change? Indeed. The old version returned false on Fedora 7, the new version returns true. Meaning in particular that several tests in TestTaskObserver and TestTaskObserver now run while they didn't before this patch. But this doesn't seem to be the root cause for the execvp issues. The thing that worked around it for me for now seems to be to disable the frysk.rt.TestStepping.testASMSingleStep() test that seems to fail with ERROR java.lang.ArrayIndexOutOfBoundsException: 0 Apparently this failure causes no more file descriptors to be available. Reported as http://sourceware.org/bugzilla/show_bug.cgi?id=4751 And adjusted the TestStepping accordingly. 2007-07-09 Mark Wielaard * TestStepping.java (testASMSingleStep): Add unresolved for bug #4751. Cheers, Mark diff -u -r1.39 TestStepping.java --- frysk-core/frysk/rt/TestStepping.java 5 Jul 2007 03:01:50 -0000 1.39 +++ frysk-core/frysk/rt/TestStepping.java 9 Jul 2007 09:23:40 -0000 @@ -254,6 +254,9 @@ if (unresolvedOnPPC(3277)) return; + if (unresolved(4751)) + return; + initial = true; this.lineMap = new HashMap(); From cagney@redhat.com Mon Jul 9 12:38:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 09 Jul 2007 12:38:00 -0000 Subject: elfutls using assert Message-ID: <46922C3E.9040301@redhat.com> Roland, Mike and I noticed that elfutils uses assert() which, in turn, calls abort(). Is there a way to override this, having the code instead call a callback? That way, should an assertion fail, frysk will be able to at least report the issue before exiting. Andrew From cagney@redhat.com Mon Jul 9 12:50:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 09 Jul 2007 12:50:00 -0000 Subject: Many new test failures (execvp: Too many open files) In-Reply-To: <1183973147.3654.23.camel@dijkstra.wildebeest.org> References: <1183641175.32586.34.camel@dijkstra.wildebeest.org> <468CFEE8.7050900@redhat.com> <1183648429.32586.47.camel@dijkstra.wildebeest.org> <468D18E2.3080700@redhat.com> <1183973147.3654.23.camel@dijkstra.wildebeest.org> Message-ID: <46922F26.4040408@redhat.com> Mike and I tracked down the likely cause - Dwfl's aren't been cleaned up aggressively enough (something that is dependent on many things including the garbage collector). We're making two changes: - adding teardown code to frysk.dwfl that will close all open Dwfls - enabling code that closes old dwfl's as new ones are created One thing though: > Indeed. The old version returned false on Fedora 7, the new version > returns true. Meaning in particular that several tests in > TestTaskObserver and TestTaskObserver now run while they didn't before > this patch. But this doesn't seem to be the root cause for the execvp > issues. > This is not correct. unresolvedOnUtrace returning TRUE causes the test to be _skipped_; so this causes less tests to be run. Given that Fedora 7 has UTRACE, it appears I fixed a latent bug. Andrew From cagney@redhat.com Mon Jul 9 13:43:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 09 Jul 2007 13:43:00 -0000 Subject: [patch] Breakpoint - only reset instruction bytes covered by breakpoint instruction bytes In-Reply-To: <1183969101.3654.5.camel@dijkstra.wildebeest.org> References: <1183969101.3654.5.camel@dijkstra.wildebeest.org> Message-ID: <46923B73.4050000@redhat.com> Please use the ByteBuffer's bulk get/put methods. Andrew Mark Wielaard wrote: > Hi, > > This is kind of an micro optimization. But it was noticable during a > trace while investigating breakpoint set/reset behavior. And potentially > setting bytes in the inferior is expensive. So here is a little patchlet > to not do any unnecessary work while resetting (or uninstalling) a > breakpoint. > > 2007-07-09 Mark Wielaard > > * Breakpoint.java (reset): Only copy back bytes covered by > breakpiont instructions. > > Tested on x86_64/FC6, no regressions. > > Cheers, > > Mark > > ------------------------------------------------------------------------ > > Index: frysk-core/frysk/proc/Breakpoint.java > =================================================================== > RCS file: /cvs/frysk/frysk-core/frysk/proc/Breakpoint.java,v > retrieving revision 1.12 > diff -u -r1.12 Breakpoint.java > --- frysk-core/frysk/proc/Breakpoint.java 2 Jul 2007 14:40:16 -0000 1.12 > +++ frysk-core/frysk/proc/Breakpoint.java 9 Jul 2007 08:15:17 -0000 > @@ -172,13 +172,18 @@ > */ > private void reset(Task task) > { > - ByteBuffer buffer; > - > - buffer = task.getMemory(); > + ByteBuffer buffer = task.getMemory(); > buffer.position(address); > > + Isa isa = task.getIsa(); > + Instruction bpInstruction = isa.getBreakpointInstruction(); > + byte[] bp = bpInstruction.getBytes(); > + > byte[] bs = origInstruction.getBytes(); > - for (int index = 0; index < bs.length; index++) > + > + // Only need to put back the part of the original instruction > + // covered by the breakpoint instruction bytes. > + for (int index = 0; index < bp.length; index++) > buffer.putByte(bs[index]); > } > > From mark@klomp.org Mon Jul 9 15:13:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 09 Jul 2007 15:13:00 -0000 Subject: [patch] Expect correct TimeoutException Message-ID: <1183993993.3654.35.camel@dijkstra.wildebeest.org> Hi, While writing a test and not understanding why I always got a TimeoutException saying that my 5 seconds were up, while I had requested more, I suddenly realized the TimeoutException was reporting the wrong value. This patch fixes that and makes TimeoutException always report the time as used. 2007-07-09 Mark Wielaard * Expect.java (expectMilliseconds): Use supplied milli seconds for reporting TimeoutException. Tested on x86 Fedora 7, no regressions. Cheers, Mark diff -u -r1.12 Expect.java --- frysk-imports/frysk/expunit/Expect.java 13 Apr 2007 21:21:13 -0000 1.12 +++ frysk-imports/frysk/expunit/Expect.java 9 Jul 2007 15:05:30 -0000 @@ -221,7 +221,7 @@ long timeRemaining = endTime - System.currentTimeMillis (); if (timeRemaining <= 0) { logger.log (Level.FINE, "{0} match TIMEOUT\n", this); - throw new TimeoutException (timeoutSeconds); + throw new TimeoutException (timeoutMilliseconds / 1000); } logger.log (Level.FINE, From mark@klomp.org Mon Jul 9 16:32:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 09 Jul 2007 16:32:00 -0000 Subject: [patch] Make fstep really start at the first instruction Message-ID: <1183998723.3654.54.camel@dijkstra.wildebeest.org> Hi, fstep had a bug (http://sourceware.org/bugzilla/show_bug.cgi?id=4668) where it would not wait till the instruction observer would be attached which meant it would miss the first few instructions. Fixing that by blocking, waiting for the observer to be properly installed and only then continuing made fstep start in the dynamic loader. Since this is probably not what the user is interested in we now put a breakpoint at the real process entry point (which will be entered by the dynamic loader) and then insert an Instruction observer. Doing this revealed a bug in the wantToAttachContinue state that didn't handle observer addition and unblocking (I thought there was a bug report for this already, but couldn't find it). The following is a patch for all this and a new test case. frysk-core/frysk/bindir/ChangeLog 2007-07-09 Mark Wielaard Fixes bug #4668 * fstep.java: Implement TaskObserver.Code. (updateAttached): Depending on whether or not the user supplied a command line to execute or a pid to trace either put a breakpoint on the first real instruction or start tracing immediately. Return Action.BLOCK. (updateHit): New method. (addedTo): Unblock task. * TestFStep.java: New test. frysk-core/frysk/proc/live/ChangeLog 2007-07-09 Mark Wielaard * LinuxTaskState.java (wantToAttachContinue): Add handleAddObservation() and handleUnblock(). Tested on x86 Fedora 7 and x86_64 Fedora Core 6. No regressions and the new test passes. The trick of exec, attaching, blocking, inserting a code observer on the process entry point and presenting the user with the process starting at that address might also be appropriate for the fhpd and frysk-gui. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: fstepfirst.patch Type: text/x-patch Size: 6502 bytes Desc: not available URL: From cagney@redhat.com Mon Jul 9 21:02:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 09 Jul 2007 21:02:00 -0000 Subject: frysk.dwfl.DwflCache is per-thread Message-ID: <4692A262.6070109@redhat.com> Just FYI, I've simplified the DwflCache so that it caches things per-thread; and more aggressively cleans up file descriptors after a test-run. Going forward, the cache can be refined further so that it refreshes, rather than re-creates, a dwfl after a task stops. Andrew From roland@redhat.com Mon Jul 9 23:08:00 2007 From: roland@redhat.com (Roland McGrath) Date: Mon, 09 Jul 2007 23:08:00 -0000 Subject: elfutls using assert In-Reply-To: Andrew Cagney's message of Monday, 9 July 2007 08:38:22 -0400 <46922C3E.9040301@redhat.com> Message-ID: <20070709230811.DCB0C4D0585@magilla.localdomain> No, there is no way not to call abort. It is used for situations that are pathological in the same way as a clobbered pointer that might lead to a crash. If you want to improve recovery from such bugs, you might as well catch all unexpected fatal signals and diagnose gracefully there (maybe if things aren't too bad you can throw an exception from the signal handler and never consult the clobbered data structures while reporting and exiting). From mark@klomp.org Tue Jul 10 09:10:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 10 Jul 2007 09:10:00 -0000 Subject: [patch] Breakpoint - only reset instruction bytes covered by breakpoint instruction bytes In-Reply-To: <46923B73.4050000@redhat.com> References: <1183969101.3654.5.camel@dijkstra.wildebeest.org> <46923B73.4050000@redhat.com> Message-ID: <1184058613.3607.10.camel@dijkstra.wildebeest.org> On Mon, 2007-07-09 at 09:43 -0400, Andrew Cagney wrote: > Please use the ByteBuffer's bulk get/put methods. Nice idea! But there is no bulk put method in ByteBuffer (there is a bulk get(), but there are no single byte get() loops in the current code). It would be nice to have a bulk put() method to optimize things, so I filed bug http://sourceware.org/bugzilla/show_bug.cgi?id=4760 Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Tue Jul 10 09:31:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 10 Jul 2007 09:31:00 -0000 Subject: [patch] Enable TestTaskSyscallObserver.testExecSyscall() Message-ID: <1184059881.3607.14.camel@dijkstra.wildebeest.org> Hi, Sami noticed that the following call was blocked on bug #3244, but seemed to PASS fine. Verified on x86 Fedora 7 and x86_64 Fedora Core 6. 2007-07-10 Mark Wielaard * TestTaskSyscallObserver.java (testExecSyscall): Remove unresolved bug #3244. Cheers, Mark diff -u -r1.31 TestTaskSyscallObserver.java --- frysk-core/frysk/proc/TestTaskSyscallObserver.java 5 Jul 2007 03:01:50 -0000 1.31 +++ frysk-core/frysk/proc/TestTaskSyscallObserver.java 10 Jul 2007 09:30:08 -0000 @@ -1,6 +1,6 @@ // This file is part of the program FRYSK. // -// Copyright 2005, 2006, Red Hat Inc. +// Copyright 2005, 2006, 2007, Red Hat Inc. // // FRYSK is free software; you can redistribute it and/or modify it // under the terms of the GNU General Public License as published by @@ -128,10 +128,6 @@ */ public void testExecSyscall () { - - if (unresolved(3244)) - return; - // Create an unattached child process. AckProcess child = new DetachedAckProcess(); -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Tue Jul 10 09:59:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 10 Jul 2007 09:59:00 -0000 Subject: Leaving visible breakpoints in memory/core (Was: Breakpoint stepping) In-Reply-To: <1183639162.32586.24.camel@dijkstra.wildebeest.org> References: <1183573205.3598.157.camel@dijkstra.wildebeest.org> <468C7757.3050105@redhat.com> <1183639162.32586.24.camel@dijkstra.wildebeest.org> Message-ID: <1184061552.3607.25.camel@dijkstra.wildebeest.org> Hi Phil, On Thu, 2007-07-05 at 14:39 +0200, Mark Wielaard wrote: > > Though I > > suspect if you are dumping core while stepping a process one is in > > deeper trouble than one suspects ;) > > I admit to not have thought of this scenario. That is indeed troublesome > since some breakpoints might actually still be embedded in the Proc code > memory while the kernel writes out the core file. Have to think about > that. What scenarios are there for a process to dump core? And is there > any way for us to intercept and quickly remove any changes we done to > the code segments before that? After thinking about it a bit more and some off-list chatter I think there are 2 scenarios here. 1) Having our inserted breakpoints show up in memory views as used in frysk. 2) Inserted breakpoints show up in core dumps of programs we are analyzing. It is probably not worth it to worry about 2) since as you say the user has deeper troubles then. And if they want to analyse the actual core file later on it is probably even more fair to make sure the breakpoints are still in the core file so they have a real picture of what went wrong (it could even have been frysk's fault!) But 1) is a problem since it would distort the view of the user while using frysk. So there is now bug #4761 and it is on my TODO list to create a memory view that the "non-breakpoint aware" parts of Frysk will use for memory inspection. The use case is to have the fhpd or frysk-gui insert a breakpoint, stop at it, and let the user inspect the code instructions around the breakpoint. This should not show traces of the breakpoint even though frysk might still have it inserted. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Tue Jul 10 10:39:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 10 Jul 2007 10:39:00 -0000 Subject: Instruction parser (Was: Breakpoint stepping) In-Reply-To: <1183573205.3598.157.camel@dijkstra.wildebeest.org> References: <1183573205.3598.157.camel@dijkstra.wildebeest.org> Message-ID: <1184063972.3607.41.camel@dijkstra.wildebeest.org> Hi, Thanks to Andrew for suggesting to put the ptrace ssol framework text in some form to the package source file, which I will do. And to Phil for pointing out a better way to get at the start address of a process, which I have already implemented. But I was hoping for some more public feedback on the other questions I tagged on the end of that long email on suggestions for moving forward with the implementation. So I am now repeating them in separate messages with some explanation of my thinking so far. Comments more than welcome. On Wed, 2007-07-04 at 20:20 +0200, Mark Wielaard wrote: > - Instruction Parser. The framework is in place and works for the few > Instructions that are known to the instruction parse, but there are all > hand coded (see IA32InstructionParser which just handles NOP, INT3, RETQ > and one JMP variant, the X8664Instruction just delegates to the IA32 for > now). There don't seem to be libraries available to easily plugin that > would give us the fixup instructions needed. The best available is the > kprobes examples from the linux kernel which have as drawback that they > are coded to be intimately tied to the kernel/C way of doing things and > only handles instructions found in kernel space. For uprobes this should > have been extended to handle every instruction that can occur in user > space, but I haven't seen that work yet (and apparently is only > available for x86 and no other architecture at this time). Any > alternatives to look at would be appreciated. Otherwise I need to sit > down with the various instruction manuals and just code it up by hand. > (Bonus points for finding something that would not just give us ssol > fixups but also simulation of instructions when hooked to the registers > and memory of a Task). I haven't found a library yet that is suitable for providing fixup information and determining instruction validity that is usable by Frysk. Without it the ssol framework is kind of fake and we fall back to reset-stepping breakpoints, but without stop-the-world, so it keeps being unreliable. The problem with the current kprobes (and by extension uprobes) approach at the moment is that it isn't robust in the face of arbitrary user space instructions. So I will probably end up writing it myself for x86/x86_64 as suggested by Roland in this systemtap/uprobes message: http://sourceware.org/ml/systemtap/2007-q1/msg00571.html This is bug #4762 now. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Tue Jul 10 10:50:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 10 Jul 2007 10:50:00 -0000 Subject: Instruction breakpoint-stepping testsuite (Was: Breakpoint stepping) In-Reply-To: <1183573205.3598.157.camel@dijkstra.wildebeest.org> References: <1183573205.3598.157.camel@dijkstra.wildebeest.org> Message-ID: <1184064652.3607.53.camel@dijkstra.wildebeest.org> On Wed, 2007-07-04 at 20:20 +0200, Mark Wielaard wrote: > - Testsuite. The best I could come up with for now is TestInstructions > and funit-instructions.c which is a nice little framework for having a > simple assembly instructions labeled in such a way that a 'instruction > address path' can be communicated to the java side so it can do either a > full step through the program or install breakpoints on every > instruction and make sure that every step and/or breakpoint hit takes it > to the right next address. But the assembly part has to be written > completely by hand (and unsurprisingly the simple assembly program > currently used works identically on x86 and x86_64). Trying to reuse the > funit-asm.h generic assembly instructions to make it platform neutral > was really hard especially since the labels used on the C and inline > assembly side have to kept in sync and mixing C defines and asm > statements don't seem to mix very well. Also at the moment it is just > using nops and jmps to keep things simple. I guess that in the end, if > we have real instruction parsers we could try to generate them using > that. Ideas or experiences with setting something up to track individual > instructions and getting the right addresses listed appreciated. I think I know how this can be made way easier. The current setup inserts labels at every instruction. This makes it really hard to combine with the generic funit-asm.h assembly instructions since it introduces 2 layers of macros to write a simple test. And the test has to be marked up fully with the labels and a path through the program that can be checked. But the current setup already shows an easier way to do this. In TestInstructions we already do a full step through the assembly and double check that all the labels are hit in the right order. But this can be turned around. We can first do this full step through the assembly instructions and record all addresses, then we put breakpoints at every instruction that we just past and do another run with the breakpoints inserted that should then run exactly the same as before (except for hitting a breakpoint at every step of course). If we do it that way then we just need the start and end address of the instruction stream and can hopefully completely reuse funit-asm.h as long as the test writer makes sure the program always ends at the same address. I'll try and implement it as above using as much instructions from funit-asm as possible. The only tricky thing is then just coming up with a good/long enough instruction sequence to proof we really handle all those instructions out there. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Tue Jul 10 10:57:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 10 Jul 2007 10:57:00 -0000 Subject: SSOL Area (Was: Breakpoint stepping) In-Reply-To: <1183573205.3598.157.camel@dijkstra.wildebeest.org> References: <1183573205.3598.157.camel@dijkstra.wildebeest.org> Message-ID: <1184065036.3607.60.camel@dijkstra.wildebeest.org> On Wed, 2007-07-04 at 20:20 +0200, Mark Wielaard wrote: > - Single Step Out Of Line Address Area. Currently the Isa (for x86 and > x86_64 at least) just provide one address. The address of the main() > function entry point taken by just doing: > > Elf elf = new Elf(proc.getExe(), ElfCommand.ELF_C_READ); > Dwarf dwarf = new Dwarf(elf, DwarfCommand.READ, null); > DwarfDie die = DwarfDie.getDecl(dwarf, "main"); > return die.getEntryBreakpoints(); > > This works surprisingly well for a simple first approach, and programs > generally don't reenter their own main() function. But it would be nice > to either find an area that is guaranteed to never be used (again) by > the process, or to map in an executable area in the inferior that is > just used by us (maybe just making the inferior load a dummy shared > library). Again any suggestions welcome. Phil already suggested that I use the auxiliary vector of a proc to more easily get at the entry point which I have implemented now. It seems to work great. Thanks Phil. Off-list I did talk a bit about this with Andrew. And it isn't clear this is a major roadblock for now. So I am not really going to experiment for now till it is more clear that this doesn't scale. And this all depends on getting the instruction parser fully in place so we actually use the ssol implementation for most instructions. What would be a good real world testcase so see if it scales or not in practise? Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Tue Jul 10 11:14:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 10 Jul 2007 11:14:00 -0000 Subject: unresolvedOnUtrace (Was: Many new test failures (execvp: Too many open files)) In-Reply-To: <46922F26.4040408@redhat.com> References: <1183641175.32586.34.camel@dijkstra.wildebeest.org> <468CFEE8.7050900@redhat.com> <1183648429.32586.47.camel@dijkstra.wildebeest.org> <468D18E2.3080700@redhat.com> <1183973147.3654.23.camel@dijkstra.wildebeest.org> <46922F26.4040408@redhat.com> Message-ID: <1184066057.3607.67.camel@dijkstra.wildebeest.org> Hi Andrew, On Mon, 2007-07-09 at 08:50 -0400, Andrew Cagney wrote: > This is not correct. unresolvedOnUtrace returning TRUE causes the test > to be _skipped_; so this causes less tests to be run. Given that Fedora > 7 has UTRACE, it appears I fixed a latent bug. Duh, you are right, I had my results crossed. Sorry about that. But that is interesting because I now really double checked and it looks like on Fedora 7 (2.6.21-1.3228.fc7 x86 SMP) bugs #3595 and #3737 are fixed and unresolvedOnUtrace() is setting the following test results to UNRESOLVED for these 4 tests that actually PASS on my machine: Running testMultiThreadedStoppedAckDaemon(frysk.proc.TestProcStopped) ...PASS Running testMultiThreadedStoppedDetached(frysk.proc.TestProcStopped) ...PASS Running testDetachExitingMainTask(frysk.proc.TestTaskObserver) ...PASS Running testDetachExitingOtherTask(frysk.proc.TestTaskObserver) ...PASS Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cagney@redhat.com Tue Jul 10 13:52:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 10 Jul 2007 13:52:00 -0000 Subject: Leaving visible breakpoints in memory/core (Was: Breakpoint stepping) In-Reply-To: <1184061552.3607.25.camel@dijkstra.wildebeest.org> References: <1183573205.3598.157.camel@dijkstra.wildebeest.org> <468C7757.3050105@redhat.com> <1183639162.32586.24.camel@dijkstra.wildebeest.org> <1184061552.3607.25.camel@dijkstra.wildebeest.org> Message-ID: <46938F27.2030808@redhat.com> Mark, Expanding on our discussion: -> user examining memory: breakpoints invisible -> process dumps core via kernel: breakpoints are visible (no choice with current kernel infrastructure) -> user requests fcore: breakpoints should not be visible I.e., breakpoints and their implementation are not visible to the user (or beyond frysk.proc) However, for our own debugging sanity, we will also need a way to examine the raw/modified memory to see what the program is really executing :-) Andrew Mark Wielaard wrote: > Hi Phil, > > On Thu, 2007-07-05 at 14:39 +0200, Mark Wielaard wrote: > >>> Though I >>> suspect if you are dumping core while stepping a process one is in >>> deeper trouble than one suspects ;) >>> >> I admit to not have thought of this scenario. That is indeed troublesome >> since some breakpoints might actually still be embedded in the Proc code >> memory while the kernel writes out the core file. Have to think about >> that. What scenarios are there for a process to dump core? And is there >> any way for us to intercept and quickly remove any changes we done to >> the code segments before that? >> > > After thinking about it a bit more and some off-list chatter I think > there are 2 scenarios here. 1) Having our inserted breakpoints show up > in memory views as used in frysk. 2) Inserted breakpoints show up in > core dumps of programs we are analyzing. It is probably not worth it to > worry about 2) since as you say the user has deeper troubles then. And > if they want to analyse the actual core file later on it is probably > even more fair to make sure the breakpoints are still in the core file > so they have a real picture of what went wrong (it could even have been > frysk's fault!) > > But 1) is a problem since it would distort the view of the user while > using frysk. So there is now bug #4761 and it is on my TODO list to > create a memory view that the "non-breakpoint aware" parts of Frysk will > use for memory inspection. The use case is to have the fhpd or frysk-gui > insert a breakpoint, stop at it, and let the user inspect the code > instructions around the breakpoint. This should not show traces of the > breakpoint even though frysk might still have it inserted. > > Cheers, > > Mark > From pmuldoon@redhat.com Tue Jul 10 14:38:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 10 Jul 2007 14:38:00 -0000 Subject: Retooling static core file tests Message-ID: <469399C5.1070605@redhat.com> I'm going to be retooling the static corefile tests around two substantially more complex corefiles. They dynamic tests already generate a complex corefile. These newer static corefiles are multi-threaded, use floating point and have several other areas that allow for better tests, including static corefiles on their native architecture, and on non-native architectures. I mention this as there might be some noise around this area for awhile and the tests may change. Regards Phil From mark@klomp.org Tue Jul 10 15:18:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 10 Jul 2007 15:18:00 -0000 Subject: [patch] Added Articles on frysk to Documentation page Message-ID: <1184080721.3607.101.camel@dijkstra.wildebeest.org> Hi, On irc there were some questions about overview articles or tutorials about Frysk. The following for were what we could find. And since they weren't on our website I added a 'Articles on frysk' section and listed them all there: 2007-07-10 Mark Wielaard * htdocs/documentation/index.html: Add section Articles on frysk. If you know of any others please add them there. Thanks, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: articles.patch Type: text/x-patch Size: 1229 bytes Desc: not available URL: From cagney@redhat.com Tue Jul 10 15:34:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 10 Jul 2007 15:34:00 -0000 Subject: elfutls using assert In-Reply-To: <20070709230811.DCB0C4D0585@magilla.localdomain> References: <20070709230811.DCB0C4D0585@magilla.localdomain> Message-ID: <4693A6F6.8030403@redhat.com> Unless I'm mistaken, it isn't possible to attach the abort signal as it may be sent to any thread? Anyway, to make the problem more concrete, when a panic like this occurs, frysk needs time to pull all inserted breakpoints before detaching from the program and exiting. Andrew Roland McGrath wrote: > No, there is no way not to call abort. It is used for situations that are > pathological in the same way as a clobbered pointer that might lead to a > crash. If you want to improve recovery from such bugs, you might as well > catch all unexpected fatal signals and diagnose gracefully there (maybe if > things aren't too bad you can throw an exception from the signal handler > and never consult the clobbered data structures while reporting and exiting). > From cagney@redhat.com Tue Jul 10 15:46:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 10 Jul 2007 15:46:00 -0000 Subject: [patch] Breakpoint - only reset instruction bytes covered by breakpoint instruction bytes In-Reply-To: <1184058613.3607.10.camel@dijkstra.wildebeest.org> References: <1183969101.3654.5.camel@dijkstra.wildebeest.org> <46923B73.4050000@redhat.com> <1184058613.3607.10.camel@dijkstra.wildebeest.org> Message-ID: <4693A9E3.1040008@redhat.com> Mark Wielaard wrote: > On Mon, 2007-07-09 at 09:43 -0400, Andrew Cagney wrote: > >> Please use the ByteBuffer's bulk get/put methods. >> > > Interesting slip-up, fortunately you've got peek and peekFully method ready to wrap? As for micro-optimizing the PtraceByteBuffer, that is something we can pick up when there's evidence supporting the need. > Nice idea! But there is no bulk put method in ByteBuffer (there is a > bulk get(), but there are no single byte get() loops in the current > code). It would be nice to have a bulk put() method to optimize things, > so I filed bug http://sourceware.org/bugzilla/show_bug.cgi?id=4760 > > Cheers, > > Mark > From cmoller@redhat.com Tue Jul 10 16:33:00 2007 From: cmoller@redhat.com (Chris Moller) Date: Tue, 10 Jul 2007 16:33:00 -0000 Subject: [patch] Breakpoint - only reset instruction bytes covered by breakpoint instruction bytes In-Reply-To: <4693A9E3.1040008@redhat.com> References: <1183969101.3654.5.camel@dijkstra.wildebeest.org> <46923B73.4050000@redhat.com> <1184058613.3607.10.camel@dijkstra.wildebeest.org> <4693A9E3.1040008@redhat.com> Message-ID: <4693B4C5.4050001@redhat.com> Andrew Cagney wrote: > Mark Wielaard wrote: >> On Mon, 2007-07-09 at 09:43 -0400, Andrew Cagney wrote: >> >>> Please use the ByteBuffer's bulk get/put methods. >>> >> >> > Interesting slip-up, fortunately you've got peek and peekFully method > ready to wrap? As for micro-optimizing the PtraceByteBuffer, that is > something we can pick up when there's evidence supporting the need. > >> Nice idea! But there is no bulk put method in ByteBuffer I'm not entirely sure it's what you guys are talking about, but frysk-imports/frysk/sys/cni/StatelessFile.cxx supports a pwrite() that's analogous to the bulk pread(), but it was never incorporated into MemorySpaceByteBuffer because no one seemed interested. >> (there is a >> bulk get(), but there are no single byte get() loops in the current >> code). It would be nice to have a bulk put() method to optimize things, >> so I filed bug http://sourceware.org/bugzilla/show_bug.cgi?id=4760 >> >> Cheers, >> >> Mark >> > -- Chris Moller Java: the blunt scissors of programming languages. -- Dave Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From cagney@redhat.com Tue Jul 10 17:03:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 10 Jul 2007 17:03:00 -0000 Subject: [patch] Breakpoint - only reset instruction bytes covered by breakpoint instruction bytes In-Reply-To: <4693B4C5.4050001@redhat.com> References: <1183969101.3654.5.camel@dijkstra.wildebeest.org> <46923B73.4050000@redhat.com> <1184058613.3607.10.camel@dijkstra.wildebeest.org> <4693A9E3.1040008@redhat.com> <4693B4C5.4050001@redhat.com> Message-ID: <4693BBD6.904@redhat.com> Chris Moller wrote: > Andrew Cagney wrote: > >> Mark Wielaard wrote: >> >>> On Mon, 2007-07-09 at 09:43 -0400, Andrew Cagney wrote: >>> >>> >>>> Please use the ByteBuffer's bulk get/put methods. >>>> >>>> >>> >>> >> Interesting slip-up, fortunately you've got peek and peekFully method >> ready to wrap? As for micro-optimizing the PtraceByteBuffer, that is >> something we can pick up when there's evidence supporting the need. >> >> >>> Nice idea! But there is no bulk put method in ByteBuffer >>> > > It is! So just a few dots need to be connected. > I'm not entirely sure it's what you guys are talking about, but > frysk-imports/frysk/sys/cni/StatelessFile.cxx supports a pwrite() that's > analogous to the bulk pread(), but it was never incorporated into > MemorySpaceByteBuffer because no one seemed interested. > > >>> (there is a >>> bulk get(), but there are no single byte get() loops in the current >>> code). It would be nice to have a bulk put() method to optimize things, >>> so I filed bug http://sourceware.org/bugzilla/show_bug.cgi?id=4760 >>> >>> Cheers, >>> >>> Mark >>> >>> > > From ajocksch@redhat.com Tue Jul 10 17:11:00 2007 From: ajocksch@redhat.com (Adam Jocksch) Date: Tue, 10 Jul 2007 17:11:00 -0000 Subject: FHPD: actionpoints command enhanced Message-ID: <4693BD9D.8040503@redhat.com> While adding the ability to output displays to the actionpoints command, I also implemented argument parsing as per the hpd spec. Nothing is done currently for the -watch and -barrier commands, but I've left space for these to be implemented fairly easily. Down the road a more efficient way of outputting various actionpoints will need to be devised, as right now I'm iterating through all the breakpoints/displays and only outputting the items who's ids were specified in the comma-delimited list. Maybe some kind of over-reaching (or consolidated) actionpoint manager? ChangeLog (frysk-core/frysk/cli/hpd): 2007-07-10 Adam Jocksch * ActionsCommand.java: Reformatted. (handle): Now parses command line arguments; currently only the list of ids, -break, -display, -enabled, and -disabled args are accepted. * DisplayCommand.java: Reformatted. (handle): Now includes the id number of the display when it is output. From cagney@redhat.com Tue Jul 10 17:35:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 10 Jul 2007 17:35:00 -0000 Subject: meeting 2007-07-11 at 9:30 east Message-ID: <4693C37B.80007@redhat.com> This week is UI review; would anyone like to put forward something to discuss? Otherwise, there's a round table. Andrew From pmuldoon@redhat.com Tue Jul 10 18:06:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 10 Jul 2007 18:06:00 -0000 Subject: Leaving visible breakpoints in memory/core (Was: Breakpoint stepping) In-Reply-To: <1184061552.3607.25.camel@dijkstra.wildebeest.org> References: <1183573205.3598.157.camel@dijkstra.wildebeest.org> <468C7757.3050105@redhat.com> <1183639162.32586.24.camel@dijkstra.wildebeest.org> <1184061552.3607.25.camel@dijkstra.wildebeest.org> Message-ID: <4693CAB6.8060809@redhat.com> Mark Wielaard wrote: > Hi Phil, > > After thinking about it a bit more and some off-list chatter I think > there are 2 scenarios here. 1) Having our inserted breakpoints show up > in memory views as used in frysk. 2) Inserted breakpoints show up in > core dumps of programs we are analyzing. It is probably not worth it to > worry about 2) since as you say the user has deeper troubles then. And > if they want to analyse the actual core file later on it is probably > even more fair to make sure the breakpoints are still in the core file > so they have a real picture of what went wrong (it could even have been > frysk's fault!) > Well I think in the kernel dumping core there is nothing to be done with 2) other than just let it happen. I just wonder if the entry-point of the program being rewritten by Frysk in this scenario will cause confusion. In the case of fcore, we can always strip all this stuff beforehand, dump the core, and then put it all back. But in the case of gcore and google's coredumper that won't be the case. A process has no idea when a userland program like gcore/fcore is creating a coredump of it. However until there is a better place to store this stuff other than at the entry-point address, then I guess the question it sort of moot. Regards Phil > But 1) is a problem since it would distort the view of the user while > using frysk. So there is now bug #4761 and it is on my TODO list to > create a memory view that the "non-breakpoint aware" parts of Frysk will > use for memory inspection. The use case is to have the fhpd or frysk-gui > insert a breakpoint, stop at it, and let the user inspect the code > instructions around the breakpoint. This should not show traces of the > breakpoint even though frysk might still have it inserted. > > Cheers, > > Mark > From pmuldoon@redhat.com Tue Jul 10 18:11:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 10 Jul 2007 18:11:00 -0000 Subject: Retooling static core file tests In-Reply-To: <469399C5.1070605@redhat.com> References: <469399C5.1070605@redhat.com> Message-ID: <4693CBE7.7010900@redhat.com> Phil Muldoon wrote: > I'm going to be retooling the static corefile tests around two > substantially more complex corefiles. They dynamic tests already > generate a complex corefile. These newer static corefiles are > multi-threaded, use floating point and have several other areas that > allow for better tests, including static corefiles on their native > architecture, and on non-native architectures. I mention this as there > might be some noise around this area for awhile and the tests may change. > > Regards > > Phil The only test scenario that static seemed to be missing was 64 bit corefiles on 32 bit platforms. The inverse of that was covered, as well as the native corefile on native architectures in the static case. In the dynamic case, the corefile created was native to the architecture. However in the static case, as test-core in the repository was a very simple corefile I have decided to rewrite the tests to use test-core-x86 and and test-core-x8664 for all tests. The will require redoing all the test values for each test. While pedantic, it is pretty simple and better going down the road. Regards Phil From roland@redhat.com Tue Jul 10 18:47:00 2007 From: roland@redhat.com (Roland McGrath) Date: Tue, 10 Jul 2007 18:47:00 -0000 Subject: elfutls using assert In-Reply-To: Andrew Cagney's message of Tuesday, 10 July 2007 11:34:14 -0400 <4693A6F6.8030403@redhat.com> Message-ID: <20070710184623.A1F904D0585@magilla.localdomain> > Unless I'm mistaken, it isn't possible to attach the abort signal as it > may be sent to any thread? You are mistaken. If you are catching the signal, you will catch all such signals in whatever thread they are delivered. Anyway, abort is equivalent to raise (SIGABRT), which means synchronously to the calling thread (the signal will appear to happen immediately after the syscall instruction for the syscall that performs the "raise"). > Anyway, to make the problem more concrete, when a panic like this occurs, > frysk needs time to pull all inserted breakpoints before detaching from > the program and exiting. Like I said, when one of these hits, you are lucky if all memory is not randomly clobbered already. But if you just avoid anything that would call into elfutils libs at all, you might be avoiding the memory that is definitely clobbered already, and be lucky enough to survive long enough to withdraw gracefully. Thanks, Roland From pearly.zhao@oracle.com Wed Jul 11 03:19:00 2007 From: pearly.zhao@oracle.com (Zhao Shujing) Date: Wed, 11 Jul 2007 03:19:00 -0000 Subject: [patch] fix the bug of the help information of fstack Message-ID: <1184123812.31631.20.camel@dhcp-beijing-cdc-10-182-121-51.cn.oracle.com> Hi, This patch is to fix bug http://sourceware.org/bugzilla/show_bug.cgi?id=4774. $./frysk-core/frysk/bindir/fstack -help The description of option "-c" and "-a" is not right. It should be "... this is equivalent to -p functions,params,fullpath" for "-c" option and " ... this is equivalent to -p functions,params,scopes,fullpath" for "-a" option. Thanks Pearly Zhao Oracle Asia R&D Center - Beijing -------------- next part -------------- A non-text attachment was scrubbed... Name: 4774.patch Type: text/x-patch Size: 1266 bytes Desc: URL: From mark@klomp.org Wed Jul 11 08:00:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 11 Jul 2007 08:00:00 -0000 Subject: [patch] fix the bug of the help information of fstack In-Reply-To: <1184123812.31631.20.camel@dhcp-beijing-cdc-10-182-121-51.cn.oracle.com> References: <1184123812.31631.20.camel@dhcp-beijing-cdc-10-182-121-51.cn.oracle.com> Message-ID: <1184140841.4322.12.camel@dijkstra.wildebeest.org> Hi Pearly, On Wed, 2007-07-11 at 11:16 +0800, Zhao Shujing wrote: > This patch is to fix bug > http://sourceware.org/bugzilla/show_bug.cgi?id=4774. > > $./frysk-core/frysk/bindir/fstack -help > > The description of option "-c" and "-a" is not right. Thanks. Since you don't have commit access yet and it looks obviously correct I committed it with the following ChangeLog entry: 2007-07-11 Zhao Shujing Fixes bug #4774 * fstack.java (main): Correct help description of -a and -c options. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Wed Jul 11 09:47:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 11 Jul 2007 09:47:00 -0000 Subject: Leaving visible breakpoints in memory/core (Was: Breakpoint stepping) In-Reply-To: <4693CAB6.8060809@redhat.com> References: <1183573205.3598.157.camel@dijkstra.wildebeest.org> <468C7757.3050105@redhat.com> <1183639162.32586.24.camel@dijkstra.wildebeest.org> <1184061552.3607.25.camel@dijkstra.wildebeest.org> <4693CAB6.8060809@redhat.com> Message-ID: <1184147237.4322.18.camel@dijkstra.wildebeest.org> Hi Phil, On Tue, 2007-07-10 at 13:06 -0500, Phil Muldoon wrote: > Well I think in the kernel dumping core there is nothing to be done with > 2) other than just let it happen. I just wonder if the entry-point of > the program being rewritten by Frysk in this scenario will cause > confusion. In the case of fcore, we can always strip all this stuff > beforehand, dump the core, and then put it all back. But in the case of > gcore and google's coredumper that won't be the case. A process has no > idea when a userland program like gcore/fcore is creating a coredump of it. > > However until there is a better place to store this stuff other than at > the entry-point address, then I guess the question it sort of moot. Yes, but the breakpoints instructions themselves are stored in the image, only the original instruction is (if we use ssol, which is almost never at this point) (re)stored at the entry-point address. And it is the breakpoint instructions that we don't want to have in a fcore result. Since both you and Andrew mentioned it I added it as second scenario to the bug report, so I won't forget to create a testcase for that. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Wed Jul 11 09:54:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 11 Jul 2007 09:54:00 -0000 Subject: frysk-top ChangeLog In-Reply-To: <20070710160014.27101.qmail@sourceware.org> References: <20070710160014.27101.qmail@sourceware.org> Message-ID: <1184147639.4322.25.camel@dijkstra.wildebeest.org> Hi Andrew, On Tue, 2007-07-10 at 16:00 +0000, cagney@sourceware.org wrote: > Log message: > Remove stray changelog entry.x > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-top/ChangeLog.diff?cvsroot=frysk&r1=1.87&r2=1.88 Why did you remove my ChangeLog entry? I explicitly put that there to document the change and because other ChangeLog entries for htdocs related files also went into that file. If you feel they are better documented in some other ChangeLog file please just tell me instead of silently removing patches so I know why/where I should document these things. Thanks, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Wed Jul 11 12:08:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 11 Jul 2007 12:08:00 -0000 Subject: meeting 2007-07-11 at 9:30 east In-Reply-To: <4693C37B.80007@redhat.com> References: <4693C37B.80007@redhat.com> Message-ID: <1184155694.4322.28.camel@dijkstra.wildebeest.org> On Tue, 2007-07-10 at 13:35 -0400, Andrew Cagney wrote: > This week is UI review; would anyone like to put forward something to > discuss? I have a VNC session containing frysk CVS from this morning setup. Let me (mjw on irc #frysk irc.gimp.net) know if anyone wants something added to the machine for a demonstration. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cagney@redhat.com Wed Jul 11 13:34:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 11 Jul 2007 13:34:00 -0000 Subject: frysk-top ChangeLog In-Reply-To: <1184147639.4322.25.camel@dijkstra.wildebeest.org> References: <20070710160014.27101.qmail@sourceware.org> <1184147639.4322.25.camel@dijkstra.wildebeest.org> Message-ID: <4694DC53.4040903@redhat.com> htdocs do not have changelogs entries; they never have. Something more interesting is why htdocs do not get posted to frysk-cvs; I'm investigating. Mark Wielaard wrote: > Hi Andrew, > > On Tue, 2007-07-10 at 16:00 +0000, cagney@sourceware.org wrote: > >> Log message: >> Remove stray changelog entry.x >> >> Patches: >> http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-top/ChangeLog.diff?cvsroot=frysk&r1=1.87&r2=1.88 >> > > Why did you remove my ChangeLog entry? I explicitly put that there to > document the change and because other ChangeLog entries for htdocs > related files also went into that file. If you feel they are better > documented in some other ChangeLog file please just tell me instead of > silently removing patches so I know why/where I should document these > things. > > Thanks, > > Mark > From kris.van.hees@oracle.com Wed Jul 11 13:47:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Wed, 11 Jul 2007 13:47:00 -0000 Subject: frysk-top ChangeLog In-Reply-To: <4694DC53.4040903@redhat.com> References: <20070710160014.27101.qmail@sourceware.org> <1184147639.4322.25.camel@dijkstra.wildebeest.org> <4694DC53.4040903@redhat.com> Message-ID: <20070711134714.GC11657@ca-server1.us.oracle.com> This brings up the question: why don't htdocs have changelog entries? I can't see a good reason against having them, and there are benefits to having changelog entries for this stuff, either way. I also have to second Mark's opinion that simply removing his entry rather than talking about it seems a bit harsh. Obviously, Mark did feel that there was a good reason to have a changelog entry for the patch he commited. That alone should be enough reason to make this a matter to discuss. Cheers, Kris On Wed, Jul 11, 2007 at 09:34:11AM -0400, Andrew Cagney wrote: > htdocs do not have changelogs entries; they never have. > > Something more interesting is why htdocs do not get posted to frysk-cvs; > I'm investigating. > > Mark Wielaard wrote: > >Hi Andrew, > > > >On Tue, 2007-07-10 at 16:00 +0000, cagney@sourceware.org wrote: > > > >>Log message: > >> Remove stray changelog entry.x > >> > >>Patches: > >>http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-top/ChangeLog.diff?cvsroot=frysk&r1=1.87&r2=1.88 > >> > > > >Why did you remove my ChangeLog entry? I explicitly put that there to > >document the change and because other ChangeLog entries for htdocs > >related files also went into that file. If you feel they are better > >documented in some other ChangeLog file please just tell me instead of > >silently removing patches so I know why/where I should document these > >things. > > > >Thanks, > > > >Mark > > > From mark@klomp.org Wed Jul 11 14:38:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 11 Jul 2007 14:38:00 -0000 Subject: frysk-top ChangeLog In-Reply-To: <20070711134714.GC11657@ca-server1.us.oracle.com> References: <20070710160014.27101.qmail@sourceware.org> <1184147639.4322.25.camel@dijkstra.wildebeest.org> <4694DC53.4040903@redhat.com> <20070711134714.GC11657@ca-server1.us.oracle.com> Message-ID: <1184164716.4322.36.camel@dijkstra.wildebeest.org> Hi, On Wed, 2007-07-11 at 06:47 -0700, Kris Van Hees wrote: > This brings up the question: why don't htdocs have changelog entries? I > can't see a good reason against having them, and there are benefits to > having changelog entries for this stuff, either way. > > Obviously, Mark did feel that there was a good reason to have a > changelog entry for the patch he commited. To be honest I was just following what others do. As far as I know htdocs changes are documented in the ChangeLog file since that is how I found out where to document them. I also don't see much reason not to have them. I was just surprised mine got deleted without any comment. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cagney@redhat.com Wed Jul 11 15:03:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 11 Jul 2007 15:03:00 -0000 Subject: cni vs jni Message-ID: <4694F12E.6080406@redhat.com> [This was today's technical topic] What are the advantages vs disadvantages of CNI over JNI. Going forward, should Frysk stick with the GCJ specific CNI, or migrate to the more standard and accepted JNI. Discuss. - cagney noted that while CNI isn't going away, it certainly isn't being pushed [he keeps getting hints that frysk should break its dependency] - MJW noted that the JNI is far more cumbersome for accessing class data, complex data types, and callback methods. Reflection calls are needed to access those methods. On the other hand full access to reflection becomes possible. - MJW indicated that JNI works best when information is exchanged using simple types (e.g., ints) and simple interfaces. Consequently it is best to perform large chunks of work in JNI with few and thin calls to/from Java. - Tim noted [is this right] that CNI gives us a fast simple and efficient access to the Java interfaces from C++. A switch to JNI would loose that; and a loss of one of the advantages of being able to code most stuff in Java. - Swig was mentioned; Phil noted that he'd looked at that for the elfutils bindings but discarded it as it over exported the interfaces - for frysk only a focused subset of the interfaces need to be bound; Cagney also noted that Swig didn't understand the memory patterns and requirements of libraries such as elfutils. - Phil asked if it was possible to combine CNI and JNI code; cagney indicated that it was (well sort of) as it is clumsy. - cagney noted that pushing more functionality into the native layer could make it easier to add other, additional bindings (binding C++ is easier than back binding native java). Possible options - simplistically translate the bindings into JNI - push more core code into C++ and move the bindings to a higher layer - status quo Schedule? From cagney@redhat.com Wed Jul 11 15:12:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 11 Jul 2007 15:12:00 -0000 Subject: frysk-top ChangeLog In-Reply-To: <20070711134714.GC11657@ca-server1.us.oracle.com> References: <20070710160014.27101.qmail@sourceware.org> <1184147639.4322.25.camel@dijkstra.wildebeest.org> <4694DC53.4040903@redhat.com> <20070711134714.GC11657@ca-server1.us.oracle.com> Message-ID: <4694F361.2080808@redhat.com> Remember, this web-only information is already available on the web via CVS. Mark is right though, there are a few other stray change-log entries, I'll clean that up; and add a trap to ensure that any extra changelog entries don't stray into that top-level ChangeLog file. Andrew Kris Van Hees wrote: > This brings up the question: why don't htdocs have changelog entries? I > can't see a good reason against having them, and there are benefits to > having changelog entries for this stuff, either way. > > I also have to second Mark's opinion that simply removing his entry > rather than talking about it seems a bit harsh. Obviously, Mark did > feel that there was a good reason to have a changelog entry for the > patch he commited. That alone should be enough reason to make this a > matter to discuss. > > Cheers, > Kris > > On Wed, Jul 11, 2007 at 09:34:11AM -0400, Andrew Cagney wrote: > >> htdocs do not have changelogs entries; they never have. >> >> Something more interesting is why htdocs do not get posted to frysk-cvs; >> I'm investigating. >> >> Mark Wielaard wrote: >> >>> Hi Andrew, >>> >>> On Tue, 2007-07-10 at 16:00 +0000, cagney@sourceware.org wrote: >>> >>> >>>> Log message: >>>> Remove stray changelog entry.x >>>> >>>> Patches: >>>> http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-top/ChangeLog.diff?cvsroot=frysk&r1=1.87&r2=1.88 >>>> >>>> >>> Why did you remove my ChangeLog entry? I explicitly put that there to >>> document the change and because other ChangeLog entries for htdocs >>> related files also went into that file. If you feel they are better >>> documented in some other ChangeLog file please just tell me instead of >>> silently removing patches so I know why/where I should document these >>> things. >>> >>> Thanks, >>> >>> Mark >>> >>> From elena.zannoni@oracle.com Wed Jul 11 15:18:00 2007 From: elena.zannoni@oracle.com (Elena Zannoni) Date: Wed, 11 Jul 2007 15:18:00 -0000 Subject: Minutes for meeting 2007-07-11 Message-ID: <4694F4E2.2010503@oracle.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: frysk-20070711 URL: From cagney@redhat.com Wed Jul 11 15:34:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 11 Jul 2007 15:34:00 -0000 Subject: Minutes for meeting 2007-07-11 In-Reply-To: <4694F4E2.2010503@oracle.com> References: <4694F4E2.2010503@oracle.com> Message-ID: <4694F88F.6040009@redhat.com> You missed the following actions: - cagney to send out minutes - cagney to post CNI vs JNI discussion as a new thread - cagney to post 32-on-64 test enabling as a new thread From cagney@redhat.com Wed Jul 11 15:58:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 11 Jul 2007 15:58:00 -0000 Subject: enabling 32-X-64 testing on 64-bit systems Message-ID: <4694FE2A.6070607@redhat.com> [from meeting] At present the 32-on-64 tests tests are disabled, the suggestion is to enable them. More exactly, on a 64-bit system, there are the following combinations: - 64-bit funit run full test-suite using 64-bit target program binaries - 64-bit funit run full test-suite using 32-bit target program binaries - 32-bit funit run full test-suite using 32-bit target program binaries within each of those test runs, there is a collection of 32-on-64 specific tests such as: - track a 32-bit process exec-ing a 64-bit process except for the 64-bit funit using 32-bit target program case, those tests are currently skipped (untested). The rationale was that the 32-bit target programs may not be present, so disabling the tests by default prevented misleading results (e.g., only a 64-bit frysk being installed). The disadvantage is, as MJW observed, that people are not generally aware of these tests and so don't run them. The intent is to reverse this situtation: enable the 32-on-64 tests when ever possible; requiring an explicit option to disable them From cagney@redhat.com Wed Jul 11 16:25:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 11 Jul 2007 16:25:00 -0000 Subject: minutes 2007-07-11 at 9:30 east In-Reply-To: <4693C37B.80007@redhat.com> References: <4693C37B.80007@redhat.com> Message-ID: <46950488.3090700@redhat.com> Technical discussion: cni vs jni See and please follow up the e-mail: http://sources.redhat.com/ml/frysk/2007-q3/msg00084.html Round Table (Ordered roughly by last initial of first name): Teresa: Working on a mechanism to identify debug that is missing. E.x.: given /bin/bash, that /usr/lib/debug/usr/bin/bash.debug and hence bash-debuginfo should be installed Current code is calling an elfutils find-debuginfo method directly; investigating instead modeling things more after the builder-pattern where elfutils would notify (call-back) frysk of the debug-info it is looking at. [side bar: roland's indicated that the code is under review; firstly making mechanisms that simplify the task of frysk implementing the debug-info call back function (e.g., making a crc-check method available); and secondly exploring more efficient ways of confirming that the debug info matches.] Sami: Printing values of variables in a stack frame. ezannoni asked if this was hpd specific, sami answered that it was the oposite, removing hpd specific assumptions from the existing code. Has one known 64-bit bug remaining. Mark: Fixing problem where inserted breakpoints are visible when examining memory contents - users don't expect to see breakpoint instructions in their code. Adding a Task.getRawMemory which will contain what is really in memory vs getMemory which is what the user thinks is there. Rick: More work cleaning up the cdtparser - current parser doesn't handle macros well; worked around. Other misc gui fixes. Re-investigating option of moving to the CDT's latest parser; last time this was investigated it was determined that it wasn't technically possible as the parser had been heavely embedded into the CDT. Working on moving the session concept out of the gui and into the core so that it can be shared with the HPD. Phil: Adding x86-64 core-file tests so that code exercised on x86. Conducting review of current fcore code. [side bar: see enable 32-X-64 tests http://sources.redhat.com/ml/frysk/2007-q3/msg00088.html ] Tim: Task/Proc stuff of HPD; for instance a Manager to assign each task/proc HPD numbers. E.g., 0.0 is the first processes first task. Cagney asked where the code is being added - frysk.rt - cagney noted that that frysk.rt code eventually migrates to a more permanent home (e.g., frysk.stack, frysk.debuginfo, ...). Adam: Improving robustness of display command; which in turn means adding more action-point related commands to the HPD. cagney: Avoiding blockades. Tracking down memory smash problems in dwfl/elf. (Was trying to clean up the exception throw/catch code as often catch code was discarding, instead of re-throwing, exceptions) [Sidebar: dwfl/elf bindings have memory corruption problems; for instance, when the object returned by DwflModule.getElf is freed it could close out the dwfl's elf object. Apologies: Stan, Chris, Kiris, Nurdin, Mike. From elena.zannoni@oracle.com Wed Jul 11 16:55:00 2007 From: elena.zannoni@oracle.com (Elena Zannoni) Date: Wed, 11 Jul 2007 16:55:00 -0000 Subject: Minutes for meeting 2007-07-11 In-Reply-To: <4694F88F.6040009@redhat.com> References: <4694F4E2.2010503@oracle.com> <4694F88F.6040009@redhat.com> Message-ID: <46950B66.1020306@oracle.com> Can you post the minutes for the meeting I didn't attend, 2007-06-27, thanks. From aph@redhat.com Wed Jul 11 17:12:00 2007 From: aph@redhat.com (Andrew Haley) Date: Wed, 11 Jul 2007 17:12:00 -0000 Subject: cni vs jni In-Reply-To: <4694F12E.6080406@redhat.com> References: <4694F12E.6080406@redhat.com> Message-ID: <18069.3978.11236.967269@zebedee.pink> Andrew Cagney writes: > [This was today's technical topic] > Possible options > > - simplistically translate the bindings into JNI > > - push more core code into C++ and move the bindings to a higher layer > > - status quo Or port CNI to Sun's Java. It's far from impossible, and as far as I an see the only real obstacle is getting buy-in from the GNU C++ maintainers. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From roland@redhat.com Thu Jul 12 02:49:00 2007 From: roland@redhat.com (Roland McGrath) Date: Thu, 12 Jul 2007 02:49:00 -0000 Subject: Leaving visible breakpoints in memory/core (Was: Breakpoint stepping) In-Reply-To: Mark Wielaard's message of Wednesday, 11 July 2007 11:47:12 +0200 <1184147237.4322.18.camel@dijkstra.wildebeest.org> Message-ID: <20070712024947.9F7354D0489@magilla.localdomain> This is something that you get for free from the "fancy VM tricks" facilities that are still pie in the sky, but is more or less hopeless short of that. So I just wouldn't worry about it any time soon. The best I think we can do for now is just remove the breakpoints when you know it's about to dump core. This is pretty easy (at least in utrace-based interfaces) since you just catch the "signal that is about to try to dump core" event, which you were probably catching already, and it clearly distinguishes "definitely about to die" from "might run a signal handler and survive". Thanks, Roland From cagney@redhat.com Thu Jul 12 13:57:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 12 Jul 2007 13:57:00 -0000 Subject: re-split all frysk-import's CNI code into frysk-sys Message-ID: <46963363.7030500@redhat.com> I'm going to investigate moving all of the cni (bindings) code in frysk-imports moving it into frysk-sys. That would be the lib/ frysk/ and inua/ directories. At present working on those bindings is a pta as it is too easy to trigger an unnecessary re-build / re-conf when modifying a binding. This will also open the way for making parts of frysk-imports, such libunwind and elfutils optional. http://sourceware.org/bugzilla/show_bug.cgi?id=4784 From cagney@redhat.com Thu Jul 12 13:57:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 12 Jul 2007 13:57:00 -0000 Subject: cni vs jni In-Reply-To: <18069.3978.11236.967269@zebedee.pink> References: <4694F12E.6080406@redhat.com> <18069.3978.11236.967269@zebedee.pink> Message-ID: <46963159.30402@redhat.com> How does BC (binary compatible abi) fit into all this? (I know frysk's build system needs to be changed, but there are compatibility issues?) Andrew Haley wrote: > Andrew Cagney writes: > > [This was today's technical topic] > > > Possible options > > > > - simplistically translate the bindings into JNI > > > > - push more core code into C++ and move the bindings to a higher layer > > > > - status quo > > Or port CNI to Sun's Java. It's far from impossible, and as far as I > an see the only real obstacle is getting buy-in from the GNU C++ > maintainers. > > Andrew. > > From aph@redhat.com Thu Jul 12 14:00:00 2007 From: aph@redhat.com (Andrew Haley) Date: Thu, 12 Jul 2007 14:00:00 -0000 Subject: cni vs jni In-Reply-To: <46963159.30402@redhat.com> References: <4694F12E.6080406@redhat.com> <18069.3978.11236.967269@zebedee.pink> <46963159.30402@redhat.com> Message-ID: <18070.13270.760951.958499@zebedee.pink> Andrew Cagney writes: > Andrew Haley wrote: > > Andrew Cagney writes: > > > [This was today's technical topic] > > > > > Possible options > > > > > > - simplistically translate the bindings into JNI > > > > > > - push more core code into C++ and move the bindings to a higher layer > > > > > > - status quo > > > > Or port CNI to Sun's Java. It's far from impossible, and as far as I > > an see the only real obstacle is getting buy-in from the GNU C++ > > maintainers. > > > How does BC (binary compatible abi) fit into all this? > (I know frysk's build system needs to be changed, but there are > compatibility issues?) Interesting question. To be absolutely clear: you can use CNI with BC-compiled code right now, given the right compiler options, but you end up with CNI code that has to be recompiled if your Java code changes. We could change CNI so that CNI code didn't have to be recompiled when the Java code changes, and this would be a Good Thing, but it would be a bit of effort. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From cagney@redhat.com Thu Jul 12 14:04:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 12 Jul 2007 14:04:00 -0000 Subject: Using the .java -> .class -> .jar -> .a route to build frysk? Message-ID: <46963511.30404@redhat.com> At present frysk uses the path: .java -> .o -> .a to build its native code. This was forced by a number of problems with older java compilers mis-compiling, mis-re-building, and/or messing up errors when the more traditional .java -> .class route was taken. The .java -> .o route proved far more robust. Unfortunatly, now with Fedora 7++, the compiler is tuned more for the bulk .java->.class route so switching to that will improve the F7 build experience. On RHEL 4, just the ability to scratch build is needed. From pmuldoon@redhat.com Thu Jul 12 14:24:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 12 Jul 2007 14:24:00 -0000 Subject: Leaving visible breakpoints in memory/core (Was: Breakpoint stepping) In-Reply-To: <20070712024947.9F7354D0489@magilla.localdomain> References: <20070712024947.9F7354D0489@magilla.localdomain> Message-ID: <4696398B.6040404@redhat.com> Roland McGrath wrote: > This is something that you get for free from the "fancy VM tricks" > facilities that are still pie in the sky, but is more or less hopeless > short of that. So I just wouldn't worry about it any time soon. The best > I think we can do for now is just remove the breakpoints when you know it's > about to dump core. This is pretty easy (at least in utrace-based > interfaces) since you just catch the "signal that is about to try to dump > core" event, which you were probably catching already, and it clearly > distinguishes "definitely about to die" from "might run a signal handler > and survive". > > I'm torn between whether tools like fcore (well only fcore in this instance) should just leave things as they are and construct core of the process "as is". Depends on the definition of a coredump and whether prettying up the process by removing bps, and other blockers is a "good thing" before a userland coredump. Or whether we should just dump it, warts and all. The second question speaks to a Frysk mechanics question, if we do remove all the bits, then dump core, can we replace them exactly as they were before? I'd like to say yes, but I get the nagging feeling this isn't so? What do others think? Phil From cagney@redhat.com Thu Jul 12 15:10:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 12 Jul 2007 15:10:00 -0000 Subject: elfutls using assert In-Reply-To: <20070710184623.A1F904D0585@magilla.localdomain> References: <20070710184623.A1F904D0585@magilla.localdomain> Message-ID: <46964453.1010608@redhat.com> Roland McGrath wrote: >> Unless I'm mistaken, it isn't possible to attach the abort signal as it >> may be sent to any thread? >> > > Good, I'll add code to attempt that. > You are mistaken. If you are catching the signal, you will catch all such > signals in whatever thread they are delivered. Anyway, abort is equivalent > to raise (SIGABRT), which means synchronously to the calling thread (the > signal will appear to happen immediately after the syscall instruction for > the syscall that performs the "raise"). > > >> Anyway, to make the problem more concrete, when a panic like this occurs, >> frysk needs time to pull all inserted breakpoints before detaching from >> the program and exiting. >> > > Like I said, when one of these hits, you are lucky if all memory is not > randomly clobbered already. But if you just avoid anything that would call > into elfutils libs at all, you might be avoiding the memory that is > definitely clobbered already, and be lucky enough to survive long enough to > withdraw gracefully. > > > Thanks, > Roland > From cagney@redhat.com Thu Jul 12 15:27:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 12 Jul 2007 15:27:00 -0000 Subject: consolidate lib.elf and lib.dw bindings into a single lib.eu (elfutils) package Message-ID: <469642CF.3010007@redhat.com> Hello, At present the lib.dw and lib.elf bindings share things via some public interfaces and fields. Given their very tightly coupled nature I intend consolidating these bindings (lib.elf and lib.eu) into a single (lib.eu) package. (For want of a better name :-) http://sourceware.org/bugzilla/show_bug.cgi?id=4786 Andrew From cagney@redhat.com Thu Jul 12 15:29:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 12 Jul 2007 15:29:00 -0000 Subject: Elf and Dwarf from DwflModule life times? Message-ID: <469648D8.6080302@redhat.com> Roland, I'm trying to understand the lifetime of the Elf and Dwarf objects returned by the dwfl_module_getelf and dwfl_module_getdwarf methods. Is there anything explaining this, in the header, say? Andrew From ajocksch@redhat.com Thu Jul 12 17:58:00 2007 From: ajocksch@redhat.com (Adam Jocksch) Date: Thu, 12 Jul 2007 17:58:00 -0000 Subject: Strange behavior with the fhpd Message-ID: <46966BD3.7000303@redhat.com> I've been encountering strange behavior with fhpd since I updated this morning. For some reason breakpoints are being hit, but the scope information and symbol table aren't behaving as they should. Here's an example session to show you what I mean: http://pastebin.ca/616520 From scox@redhat.com Thu Jul 12 20:19:00 2007 From: scox@redhat.com (Stan Cox) Date: Thu, 12 Jul 2007 20:19:00 -0000 Subject: Strange behavior with the fhpd In-Reply-To: <46966BD3.7000303@redhat.com> References: <46966BD3.7000303@redhat.com> Message-ID: <1184271325.3010.15.camel@multics.rdu.redhat.com> On Thu, 2007-07-12 at 11:58 -0600, Adam Jocksch wrote: > I've been encountering strange behavior with fhpd since I updated this morning. Might be related to the current frame removal; looking now. From roland@redhat.com Thu Jul 12 20:24:00 2007 From: roland@redhat.com (Roland McGrath) Date: Thu, 12 Jul 2007 20:24:00 -0000 Subject: Leaving visible breakpoints in memory/core (Was: Breakpoint stepping) In-Reply-To: Phil Muldoon's message of Thursday, 12 July 2007 09:24:11 -0500 <4696398B.6040404@redhat.com> Message-ID: <20070712202339.A4D064D0489@magilla.localdomain> For a nondestructive dump, you also have the option of editting the memory as you copy it. From roland@redhat.com Thu Jul 12 20:32:00 2007 From: roland@redhat.com (Roland McGrath) Date: Thu, 12 Jul 2007 20:32:00 -0000 Subject: Elf and Dwarf from DwflModule life times? In-Reply-To: Andrew Cagney's message of Thursday, 12 July 2007 11:29:28 -0400 <469648D8.6080302@redhat.com> Message-ID: <20070712203150.BFD024D0489@magilla.localdomain> > I'm trying to understand the lifetime of the Elf and Dwarf objects > returned by the dwfl_module_getelf and dwfl_module_getdwarf methods. Everything you get from libdwfl about a particular module is live while that module is live. You have to assume it all gets freed and becomes invalid pointers when the module is removed. A module gets removed at the end of a reporting pass that did not report it, when your dwfl_report_end call will make callbacks to its REMOVED argument. (And of course all the modules go away at dwfl_end.) > Is there anything explaining this, in the header, say? I don't think it is very clear anywhere. (I always figured the details of the reporting stuff might change a little when nontrivial users came along.) There is a longer-term plan for caching and sharing that will complicate the situation with the potential for options other than eagerly dropping everything when a module dies. (It may soon be about time for that work.) But the conservative rules for callers now will continue to be safe. Thanks, Roland From cagney@redhat.com Thu Jul 12 21:37:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 12 Jul 2007 21:37:00 -0000 Subject: Elf and Dwarf from DwflModule life times? In-Reply-To: <20070712203150.BFD024D0489@magilla.localdomain> References: <20070712203150.BFD024D0489@magilla.localdomain> Message-ID: <46969F37.60208@redhat.com> Roland McGrath wrote: >> I'm trying to understand the lifetime of the Elf and Dwarf objects >> returned by the dwfl_module_getelf and dwfl_module_getdwarf methods. >> > > Everything you get from libdwfl about a particular module is live while > that module is live. You have to assume it all gets freed and becomes > invalid pointers when the module is removed. A module gets removed at the > end of a reporting pass that did not report it, when your dwfl_report_end > call will make callbacks to its REMOVED argument. (And of course all the > modules go away at dwfl_end.) > > Ok, thanks. I just figured out that "fildes" is copied (not duped) when elf_clone is called; we'll need to be careful there as well. Andrew >> Is there anything explaining this, in the header, say? >> > > I don't think it is very clear anywhere. (I always figured the details of > the reporting stuff might change a little when nontrivial users came along.) > > There is a longer-term plan for caching and sharing that will complicate > the situation with the potential for options other than eagerly dropping > everything when a module dies. (It may soon be about time for that work.) > But the conservative rules for callers now will continue to be safe. > > > Thanks, > Roland > > > From roland@redhat.com Thu Jul 12 22:24:00 2007 From: roland@redhat.com (Roland McGrath) Date: Thu, 12 Jul 2007 22:24:00 -0000 Subject: Elf and Dwarf from DwflModule life times? In-Reply-To: Andrew Cagney's message of Thursday, 12 July 2007 17:37:59 -0400 <46969F37.60208@redhat.com> Message-ID: <20070712222441.B7A164D0489@magilla.localdomain> > I just figured out that "fildes" is copied (not duped) when elf_clone is > called; we'll need to be careful there as well. I can't imagine why you would ever use elf_clone. Anyway, yes, libelf does nothing special to manage file descriptors. libdwfl manages the file descriptors. From scox@redhat.com Thu Jul 12 23:14:00 2007 From: scox@redhat.com (Stan Cox) Date: Thu, 12 Jul 2007 23:14:00 -0000 Subject: Strange behavior with the fhpd In-Reply-To: <1184271325.3010.15.camel@multics.rdu.redhat.com> References: <46966BD3.7000303@redhat.com> <1184271325.3010.15.camel@multics.rdu.redhat.com> Message-ID: <1184281802.3010.41.camel@multics.rdu.redhat.com> Looks like a timing issue. I think this is what is happening: Currently: frysk.cli.hpd.CLI.finishAttach -> frysk.stack.StackFactory.createFrame (sometimes you end up only with start, this is Adam's problem) Previously: as above...but later frysk.cli.hpd.CLI.refreshSymtab -> frysk.debuginfo.DebugInfo.refresh -> frysk.debuginfo.DebugInfoEvaluator.refreshCurrentFrame -> -> frysk.stack.StackFactory.createFrame Looks like it will be necessary to either delay the setup of frame or resurrect some form of the refresh machinery. From pmuldoon@redhat.com Fri Jul 13 03:07:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 13 Jul 2007 03:07:00 -0000 Subject: frysk-imports/lib/elf ChangeLog tests/TestElf.java In-Reply-To: <20070712185956.9810.qmail@sourceware.org> References: <20070712185956.9810.qmail@sourceware.org> Message-ID: <4696EC60.9010302@redhat.com> > Modified files: > lib/elf : ChangeLog > lib/elf/tests : TestElf.java > > Log message: > 2007-07-12 Phil Muldoon > > * tests/TestElf.java (testCore): Deleted > (testElfCorePrpsNotes): Deleted. > (testElfCorePrstatusNotes): Deleted. > (testElfCorePrAuxvNotes): Deleted. > (testCore_x86): New. Rewritten from old version > to test cross ISA situations > (testElfCorePrpsNotes_x86): Ditto. > (testElfCorePrstatusNotes_x86): Ditto. > (testElfCorePrAuxvNotes_x86): Ditto. > (testCore_x8664): Ditto. > (testElfCorePrpsNotes_x8664): Ditto. > (testElfCorePrstatusNotes_x8664): Ditto. > (testElfCorePrAuxvNotes_x8664): Ditto. > > This patch concludes the Elf sections of the core file test change. There are now two sets of each test, one for each corefile. This covers (at least core file elf access) the following scenarios depending on the test hardware matrix the tests are executed on. Tests on a 32 bit platform: 32 bit core file on 32 bit platform 64 bit core file on 32 bit platform Little endian core files on a little endian system Big endian core files on a little endian system Tests on a 64 bit platform: 32 bit core file on 64 bit platform 64 bit core file on a 64 bit platform Little endian core files on a big endian system Big endian core files on a big end system Additionally the tests now test multiple-thread core files more thoroughly, checking all the registers in each thread for sanity as well as checking for existence of corresponding floating point data. This is in addition to the usual and existing note tests that existed before. The second step is to phase out usage of the old, very simple "test-core" core file in frysk-core, and translate those tests to use the more complex and demanding new corefiles that were checked in last week. At that time, the old test-core can be deleted. Regards Phil From scox@redhat.com Fri Jul 13 03:17:00 2007 From: scox@redhat.com (Stan Cox) Date: Fri, 13 Jul 2007 03:17:00 -0000 Subject: Strange behavior with the fhpd In-Reply-To: <46966BD3.7000303@redhat.com> References: <46966BD3.7000303@redhat.com> Message-ID: <1184296407.3010.45.camel@multics.rdu.redhat.com> On Thu, 2007-07-12 at 11:58 -0600, Adam Jocksch wrote: > I've been encountering strange behavior with fhpd * CLI.java (SteppingObserver.update): Update frame. From cagney@redhat.com Fri Jul 13 13:23:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 13 Jul 2007 13:23:00 -0000 Subject: Strange behavior with the fhpd In-Reply-To: <1184281802.3010.41.camel@multics.rdu.redhat.com> References: <46966BD3.7000303@redhat.com> <1184271325.3010.15.camel@multics.rdu.redhat.com> <1184281802.3010.41.camel@multics.rdu.redhat.com> Message-ID: <46977CFA.4020308@redhat.com> Stan Cox wrote: > Looks like a timing issue. I think this is what is happening: > > Currently: > frysk.cli.hpd.CLI.finishAttach -> frysk.stack.StackFactory.createFrame > (sometimes you end up only with start, this is Adam's problem) > > I don't think it will be a timing issue. Looking at this: 1. [ajocksch@localhost frysk-core]$ frysk/bindir/fhpd /home/ajocksch/build/frysk/frysk-core/frysk/pkglibdir/funit-rt-varchange 2. Attached to process 14184 3. (fhpd) where 4. #0 0x006a58d0 in _start () I'm surprised it is still in _start. 1. (fhpd) break @funit-rt-varchange.c@52 2. breakpoint 0 3. (fhpd) go 4. (fhpd) Breakpoint 0 @funit-rt-varchange.c@52 5. where 6. #0 0x006a58d0 in _start () A guess is that something is trying to be more efficient by caching locally instead of leaving it to a lower level. This often happens when the LHS with refresh is fighting the RHS using on-demand. I'd suggest a step sideways here and remove all caching for now; do everything on-demand. 1. (fhpd) display x 2. 1: x = 3. (fhpd) > Previously: > as above...but later > frysk.cli.hpd.CLI.refreshSymtab -> frysk.debuginfo.DebugInfo.refresh -> > frysk.debuginfo.DebugInfoEvaluator.refreshCurrentFrame -> > -> frysk.stack.StackFactory.createFrame > > Looks like it will be necessary to either delay the setup of frame or > resurrect some form of the refresh machinery. > > > > From cagney@redhat.com Fri Jul 13 13:49:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 13 Jul 2007 13:49:00 -0000 Subject: consolidate lib.elf and lib.dw bindings into a single lib.eu (elfutils) package In-Reply-To: <469642CF.3010007@redhat.com> References: <469642CF.3010007@redhat.com> Message-ID: <469782FC.5060209@redhat.com> I thought of a better name; put everything in lib.elf :-) Andrew Cagney wrote: > Hello, > > At present the lib.dw and lib.elf bindings share things via some > public interfaces and fields. Given their very tightly coupled nature > I intend consolidating these bindings (lib.elf and lib.eu) into a > single (lib.eu) package. (For want of a better name :-) > > http://sourceware.org/bugzilla/show_bug.cgi?id=4786 > > Andrew > From kris.van.hees@oracle.com Fri Jul 13 13:52:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Fri, 13 Jul 2007 13:52:00 -0000 Subject: WARNING: The tree in CVS is currently broken Message-ID: <20070713135208.GB17564@ca-server1.us.oracle.com> The build is currently failing with the following error: ./frysk/sys/FileDescriptor.h: In member function 'java::lang::String* frysk::sys::PseudoTerminal::getName()': ./frysk/sys/FileDescriptor.h:57: error: 'jint frysk::sys::FileDescriptor::fd' is private /home/frysk/build_farm/frysk_fresh/frysk_config/frysk-imports/frysk/sys/cni/PseudoTerminal.cxx:85: error: within this context make[3]: *** [frysk/sys/cni/PseudoTerminal.o] Error 1 From cagney@redhat.com Fri Jul 13 14:47:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 13 Jul 2007 14:47:00 -0000 Subject: WARNING: The tree in CVS is currently broken In-Reply-To: <20070713135208.GB17564@ca-server1.us.oracle.com> References: <20070713135208.GB17564@ca-server1.us.oracle.com> Message-ID: <4697908B.2000008@redhat.com> Both this and a lingering reference to Accessors.h have been fixed; Seem's I'm having a friday the 13th. Sorry. Andrew Kris Van Hees wrote: > The build is currently failing with the following error: > > ./frysk/sys/FileDescriptor.h: In member function 'java::lang::String* frysk::sys::PseudoTerminal::getName()': > ./frysk/sys/FileDescriptor.h:57: error: 'jint frysk::sys::FileDescriptor::fd' is private > /home/frysk/build_farm/frysk_fresh/frysk_config/frysk-imports/frysk/sys/cni/PseudoTerminal.cxx:85: error: within this context > make[3]: *** [frysk/sys/cni/PseudoTerminal.o] Error 1 > From scox@redhat.com Fri Jul 13 19:47:00 2007 From: scox@redhat.com (Stan Cox) Date: Fri, 13 Jul 2007 19:47:00 -0000 Subject: Strange behavior with the fhpd In-Reply-To: <46977CFA.4020308@redhat.com> References: <46966BD3.7000303@redhat.com> <1184271325.3010.15.camel@multics.rdu.redhat.com> <1184281802.3010.41.camel@multics.rdu.redhat.com> <46977CFA.4020308@redhat.com> Message-ID: <1184355796.3010.50.camel@multics.rdu.redhat.com> With the patch committed last night that resurrects a simpler form of the refresh machinery I get the following. Mind you I didn't investigate why it is in start prior to the refresh. (fhpd) break bar breakpoint 0 (fhpd) go (fhpd) Breakpoint 0 bar where #0 0x00000000004004ae in bar () #1 0x0000000000400461 in main () #2 0x0000003c54a1daa4 in __libc_start_main () #3 0x0000000000400399 in _start () (fhpd) go (fhpd) Breakpoint 0 bar where #0 0x00000000004004ae in bar () #1 0x0000000000400476 in main () #2 0x0000003c54a1daa4 in __libc_start_main () #3 0x0000000000400399 in _start () (fhpd) print x 1 (fhpd) From mark@klomp.org Sat Jul 14 01:01:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Sat, 14 Jul 2007 01:01:00 -0000 Subject: enabling 32-X-64 testing on 64-bit systems In-Reply-To: <4694FE2A.6070607@redhat.com> References: <4694FE2A.6070607@redhat.com> Message-ID: <1184374870.3632.74.camel@dijkstra.wildebeest.org> Hi Andrew, On Wed, 2007-07-11 at 11:58 -0400, Andrew Cagney wrote: > The disadvantage is, as MJW observed, that people are not generally > aware of these tests and so don't run them. > > The intent is to reverse this situtation: enable the 32-on-64 tests when > ever possible; requiring an explicit option to disable them I think that is a good idea. I have to admit I still haven't figured out how to enable them currently. I did find the --enable-arch32-tests autogen/configure flag, but it looks like that is already enabled on x86_64 by default. Do I need anything else? Thanks, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tromey@redhat.com Sun Jul 15 18:14:00 2007 From: tromey@redhat.com (Tom Tromey) Date: Sun, 15 Jul 2007 18:14:00 -0000 Subject: typo in druid UI Message-ID: I happened to notice today that the file ./frysk-gui/frysk/gui/gladedir/frysk_create_session_druid.glade has "Session" misspelled as "Sesison". Tom From mark@klomp.org Mon Jul 16 08:44:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 16 Jul 2007 08:44:00 -0000 Subject: typo in druid UI In-Reply-To: References: Message-ID: <1184575473.3628.5.camel@dijkstra.wildebeest.org> Hi Tom, On Sun, 2007-07-15 at 11:57 -0600, Tom Tromey wrote: > I happened to notice today that the file > ./frysk-gui/frysk/gui/gladedir/frysk_create_session_druid.glade > > has "Session" misspelled as "Sesison". Thanks. Fixed as follows: 2007-07-16 Mark Wielaard * gladedir/frysk_create_session_druid.glade (label128): Monitoring. Fixed spelling of Session. Cheers, Mark diff -u -r1.11 frysk_create_session_druid.glade --- frysk-gui/frysk/gui/gladedir/frysk_create_session_druid.glade 11 Jun 2007 15:03:20 -0000 1.11 +++ frysk-gui/frysk/gui/gladedir/frysk_create_session_druid.glade 16 Jul 2007 08:43:50 -0000 @@ -396,7 +396,7 @@ True - Create a Frysk Monitoring Sesison to monitor running processes, collect information, with minimal interference with their execution with the option to move to a tradional Debugging Session when needed. + Create a Frysk Monitoring Session to monitor running processes, collect information, with minimal interference with their execution with the option to move to a tradional Debugging Session when needed. False False GTK_JUSTIFY_LEFT -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Mon Jul 16 09:19:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 16 Jul 2007 09:19:00 -0000 Subject: [patch] Re: Instruction breakpoint-stepping testsuite (Was: Breakpoint stepping) In-Reply-To: <1184064652.3607.53.camel@dijkstra.wildebeest.org> References: <1183573205.3598.157.camel@dijkstra.wildebeest.org> <1184064652.3607.53.camel@dijkstra.wildebeest.org> Message-ID: <1184577580.3628.23.camel@dijkstra.wildebeest.org> Hi, On Tue, 2007-07-10 at 12:50 +0200, Mark Wielaard wrote: > I think I know how this can be made way easier. The current setup > inserts labels at every instruction. This makes it really hard to > combine with the generic funit-asm.h assembly instructions since it > introduces 2 layers of macros to write a simple test. And the test has > to be marked up fully with the labels and a path through the program > that can be checked. But the current setup already shows an easier way > to do this. In TestInstructions we already do a full step through the > assembly and double check that all the labels are hit in the right > order. But this can be turned around. We can first do this full step > through the assembly instructions and record all addresses, then we put > breakpoints at every instruction that we just past and do another run > with the breakpoints inserted that should then run exactly the same as > before (except for hitting a breakpoint at every step of course). > > If we do it that way then we just need the start and end address of the > instruction stream and can hopefully completely reuse funit-asm.h as > long as the test writer makes sure the program always ends at the same > address. The above is what the following patch implements. The test is replaced by a full .S assembly file that only uses instructions as defined in frysk-asm.h. It creates 2 global labels istart and iend inside the test function (instructions) that are used by the rewitten TestInstructions harness which now assumes setting a breakpoint, stopping and removing it (to detect istart) and instruction stepping (till iend is detected) work (which is a good assumption to make since we have other unit tests that explicitly test this) in setup(). Then each different test then sets breakpoints on the addresses collected between istart and iend and the test function is called again by funit-instructions and each test checks that the same instruction sequence is hit independent from which Code breakpoint (and/or other) observers are inserted. frysk-core/frysk/proc/ChangeLog 2007-07-13 Mark Wielaard * TestInstructions.java (pid, proc, in, out, labels): Removed fields. (addresses, io, start_address, end_address): New fields. (getGlobalLabelAddress): New method. (Symbol): New static class. (setup): Rewritten to no use ForkLib and to use Code and Instruction observer to find code instruction path. (tearDown): Clear addresses. (testBreakAndStepInstructions): Renamed to... (testBreakOnStartThenStepAllInstructions): Rewriten to use addresses, breakpoint on first, delete, then step all. (testAllBreakpoints): Rewritten to use addresses. (testInsertAllBreakpointsAndStepAll): New test. (InstructionObserver.block): New field. (InstructionObserver.deletedFrom): Don't stop event loop. (InstructionObserver.updateExecuted): Check block field. (InstructionObserver.setBlock): New method. frysk-core/frysk/pkglibdir/ChangeLog 2007-07-13 Mark Wielaard * funit-instructions.c: Removed. * funit-instructions.S: New file. Tested on x86_64 and x86. The instruction sequences have been extended a bit to exercise many of the generic instructions found in frysk-asm.h. The next thing would be extending these sequences with full architecture specific instructions. Which has to be added when we have a full ssol instruction parser. When cross 32-64 bit tests are enabled funit-instructions should now just compile and run as is in either 32 or 64 bit mode. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: instructions-test.patch Type: text/x-patch Size: 20225 bytes Desc: not available URL: From mark@klomp.org Mon Jul 16 10:30:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 16 Jul 2007 10:30:00 -0000 Subject: [patch] Replacing Exe with File.getCanonicalPath() Message-ID: <1184581826.3628.33.camel@dijkstra.wildebeest.org> Hi, While Phil, Rick and me were investigation bug #4788 we noticed that frysk.sys.Exe just does what File.getCanonicalPath() provides. Since the way Exe calls readlink is somewhat non-conventional by allocation large arrays on the stack which isn't recommended by the glibc manual and Exe doesn't actually come with any test code I replaced the only usage of it in frysk with File.getCanonicalPath(). frysk-core/frysk/proc/live/ChangeLog 2007-07-16 Mark Wielaard * LinuxProc.java (sendrecExe): Use File.getCanonicalPath(). frysk-imports/frysk/sys/proc/ChangeLog 2007-07-16 Mark Wielaard * Exe.java: Removed. * cni/Exe.cxx: Likewise. Tested on x86_64 and x86 without regressions, also smoke tested FryskGui. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: exe-canonical.patch Type: text/x-patch Size: 7677 bytes Desc: not available URL: From cagney@redhat.com Mon Jul 16 14:39:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 16 Jul 2007 14:39:00 -0000 Subject: enabling 32-X-64 testing on 64-bit systems In-Reply-To: <1184374870.3632.74.camel@dijkstra.wildebeest.org> References: <4694FE2A.6070607@redhat.com> <1184374870.3632.74.camel@dijkstra.wildebeest.org> Message-ID: <469B831A.2010902@redhat.com> See TestRunner --arch 32, it's in the funit man page. Mark Wielaard wrote: > Hi Andrew, > > On Wed, 2007-07-11 at 11:58 -0400, Andrew Cagney wrote: > >> The disadvantage is, as MJW observed, that people are not generally >> aware of these tests and so don't run them. >> >> The intent is to reverse this situtation: enable the 32-on-64 tests when >> ever possible; requiring an explicit option to disable them >> > > I think that is a good idea. I have to admit I still haven't figured out > how to enable them currently. I did find the --enable-arch32-tests > autogen/configure flag, but it looks like that is already enabled on > x86_64 by default. Do I need anything else? > > Thanks, > > Mark > From swagiaal@redhat.com Mon Jul 16 14:44:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Mon, 16 Jul 2007 14:44:00 -0000 Subject: typo in druid UI In-Reply-To: <1184575473.3628.5.camel@dijkstra.wildebeest.org> References: <1184575473.3628.5.camel@dijkstra.wildebeest.org> Message-ID: <469B8434.3010600@redhat.com> Thanx Tom and Mark :) Mark Wielaard wrote: > Hi Tom, > > On Sun, 2007-07-15 at 11:57 -0600, Tom Tromey wrote: > >> I happened to notice today that the file >> ./frysk-gui/frysk/gui/gladedir/frysk_create_session_druid.glade >> >> has "Session" misspelled as "Sesison". >> > > Thanks. Fixed as follows: > > 2007-07-16 Mark Wielaard > > * gladedir/frysk_create_session_druid.glade (label128): > Monitoring. Fixed spelling of Session. > > Cheers, > > Mark > > diff -u -r1.11 frysk_create_session_druid.glade > --- frysk-gui/frysk/gui/gladedir/frysk_create_session_druid.glade 11 Jun 2007 15:03:20 -0000 1.11 > +++ frysk-gui/frysk/gui/gladedir/frysk_create_session_druid.glade 16 Jul 2007 08:43:50 -0000 > @@ -396,7 +396,7 @@ > > > True > - Create a Frysk Monitoring Sesison to monitor running processes, collect information, with minimal interference with their execution with the option to move to a tradional Debugging Session when needed. > + Create a Frysk Monitoring Session to monitor running processes, collect information, with minimal interference with their execution with the option to move to a tradional Debugging Session when needed. > False > False > GTK_JUSTIFY_LEFT > > From mark@klomp.org Mon Jul 16 15:27:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 16 Jul 2007 15:27:00 -0000 Subject: [patch] core file inserted breakpoints Message-ID: <1184599668.3628.40.camel@dijkstra.wildebeest.org> Hi, For scenario 2 from bug # 4761 I created the following testcase that checks whether breakpoint instructions inserted by frysk-core show up in the fcore generated image. 2007-07-16 Mark Wielaard * TestLinuxCore.java (testInsertedBreakpoint): New method. (getFunctionEntryAddress): New private method. (CodeObserver): New static helper class. (AttachedObserver): Likewise. As it happens they don't and the test PASSes (x86_64/FC6). This is because fcore currently writes out the elf sections as it can find them on disk. Phil and me decided it wouldn't hurt to add the testcase anyway in case the sendrecMaps() code in core gets rewritten. Then this can be a valuable testcase to show no regressions slip in. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: breakpoint-core-test.patch Type: text/x-patch Size: 5370 bytes Desc: not available URL: From ajocksch@redhat.com Mon Jul 16 15:42:00 2007 From: ajocksch@redhat.com (Adam Jocksch) Date: Mon, 16 Jul 2007 15:42:00 -0000 Subject: fhpd commands extended to include displays Message-ID: <469B91E6.4050507@redhat.com> As of this morning, the enable, disable, delete, and actionpoints commands have all be extended to work with displays as well as breakpoints. They also now accept all the parameters specified by the hpd spec: -enabled, -disabled, -break, -watch, -barrier along with a new -display option. Do we want to have somewhere to document the extensions to the hpd spec that we decide to implement in frysk? (i.e. the display command). Adam ChangeLogs: frysk-core/frysk/rt: 2007-07-16 Adam Jocksch * DeleteCommand.java (handle): Now parses the correct parameters as per the hpd spec. * DisableCommand.java (handle): Simplified the argument parsing logic. * EnableCommand.java (handle): Ditto. 2007-07-11 Adam Jocksch * ActionsCommand.java (handle): Now only prints out section headers if there's something in that section. * DisableCommand.java (handle): Now accepts all arguments as specified in the hpd spec. * EnableCommand.java (handle): Ditto. * DeleteCommand.java: Reformatted. (handle): Now deletes displays as well as breakpoints. * DisableCommand.java: Reformatted. (handle): Extended to disable displays as well. * EnableCommand.java: Reformatted. (handle): Extended to enable displays as well. frysk-core/frysk/rt: 2007-07-16 Adam Jocksch * DisplayManager.java (DisplayMap): Added toString method for debugging purposes. 2007-07-11 Adam Jockchch * UpdatingDisplayValue.java (enabled): Is now a no-op if already enabled. (disabled): Is now a no-op if already disabled. * DisplayManager.java (deleteDisplay): Fixed bug where display was not being removed from one of the maps. * DisplayManager.java: Reformatted. (getDisplay): Added. * UpdatingDisplayValue.java: Reformatted. (disable): No longer tells the SteppingEngine to continue. From pmuldoon@redhat.com Mon Jul 16 15:45:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Mon, 16 Jul 2007 15:45:00 -0000 Subject: [patch] core file inserted breakpoints In-Reply-To: <1184599668.3628.40.camel@dijkstra.wildebeest.org> References: <1184599668.3628.40.camel@dijkstra.wildebeest.org> Message-ID: <469B92A4.1000008@redhat.com> Mark Wielaard wrote: > As it happens they don't and the test PASSes (x86_64/FC6). This is > because fcore currently writes out the elf sections as it can find them > on disk. Phil and me decided it wouldn't hurt to add the testcase anyway > in case the sendrecMaps() code in core gets rewritten. Then this can be > a valuable testcase to show no regressions slip in. > > Mark, Quick question: Does this pass on x86? Regards Phil From mark@klomp.org Mon Jul 16 15:53:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 16 Jul 2007 15:53:00 -0000 Subject: Leaving visible breakpoints in memory/core (Was: Breakpoint stepping) In-Reply-To: <4696398B.6040404@redhat.com> References: <20070712024947.9F7354D0489@magilla.localdomain> <4696398B.6040404@redhat.com> Message-ID: <1184601180.3628.53.camel@dijkstra.wildebeest.org> Hi Phil, On Thu, 2007-07-12 at 09:24 -0500, Phil Muldoon wrote: > The second question speaks to a Frysk mechanics question, if we do > remove all the bits, then dump core, can we replace them exactly as they > were before? I'd like to say yes, but I get the nagging feeling this > isn't so? What do others think? Unless you record them somewhere you won't be able to reinsert them. I personally don't think you should record them and try to reinsert them when creating a core file through fcore because I think that the user requesting the core file to be created from frysk is interested in the original code. But if you really wanted to then you could at least get the breakpoints instructions that frysk-core inserted from BreakpointAddresses (which I will soon extend with a handy getAllAdresses() method for fixing bug #4761), and then you can get the actual breakpoint instruction bytes used from the relevant Isa getBreakpointInstruction(). This is probably too low level though. And since you cannot guarantee that the created core file is read back through frysk (someone could be using gdb!) I don't know where you would actually put this information or how you would make all consumers know about both the original bytes and the breakpoint instructions in the image. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Mon Jul 16 15:57:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 16 Jul 2007 15:57:00 -0000 Subject: Leaving visible breakpoints in memory/core (Was: Breakpoint stepping) In-Reply-To: <20070712202339.A4D064D0489@magilla.localdomain> References: <20070712202339.A4D064D0489@magilla.localdomain> Message-ID: <1184601441.3628.58.camel@dijkstra.wildebeest.org> On Thu, 2007-07-12 at 13:23 -0700, Roland McGrath wrote: > For a nondestructive dump, you also have the option of editting the memory > as you copy it. Yes, that is the plan for bug #4761 (Task Memory view without inserted breakpoints showing). There will be a getMemory() view that shows the original bytes as found in the process (with anything frysk-core might have added to it for things like breakpointing filtered out) and a getRawMemory() that gives the raw bytes as manipulated by frysk-core. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Mon Jul 16 15:59:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 16 Jul 2007 15:59:00 -0000 Subject: [patch] core file inserted breakpoints In-Reply-To: <469B92A4.1000008@redhat.com> References: <1184599668.3628.40.camel@dijkstra.wildebeest.org> <469B92A4.1000008@redhat.com> Message-ID: <1184601562.3628.60.camel@dijkstra.wildebeest.org> Hi Phil, On Mon, 2007-07-16 at 10:45 -0500, Phil Muldoon wrote: > Mark Wielaard wrote: > > As it happens they don't and the test PASSes (x86_64/FC6). This is > > because fcore currently writes out the elf sections as it can find them > > on disk. Phil and me decided it wouldn't hurt to add the testcase anyway > > in case the sendrecMaps() code in core gets rewritten. Then this can be > > a valuable testcase to show no regressions slip in. > > Quick question: Does this pass on x86? Yes! $ uname -a Linux hermans.wildebeest.org 2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 15:37:31 EDT 2007 i686 i686 i386 GNU/Linux $ ./TestRunner frysk.proc.dead.TestLinuxCore Running testLinuxCoreFileMaps(frysk.proc.dead.TestLinuxCore) ...PASS Running testLinuxCoreFileStackTrace(frysk.proc.dead.TestLinuxCore) ...PASS Running testLinuxHostPopulation(frysk.proc.dead.TestLinuxCore) ...PASS Running testLinuxProcPopulation(frysk.proc.dead.TestLinuxCore) ...PASS Running testLinuxProcAuxV(frysk.proc.dead.TestLinuxCore) ...PASS Running testLinuxTaskMemory(frysk.proc.dead.TestLinuxCore) ...PASS Running testLinuxTaskPopulation(frysk.proc.dead.TestLinuxCore) ...PASS Running testInsertedBreakpoint(frysk.proc.dead.TestLinuxCore) ...PASS Time: 0.468 OK (8 tests) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From npremji@redhat.com Mon Jul 16 20:05:00 2007 From: npremji@redhat.com (Nurdin Premji) Date: Mon, 16 Jul 2007 20:05:00 -0000 Subject: Elfutils module reporting Message-ID: <469BCF76.50103@redhat.com> Roland, I'm trying to refresh dwfl objects in terms of the dwfl_modules. To optimize code and not create a new dwfl object every time a task changes. As a first pass I was trying to remove all old modules and re-report new modules just by using dwfl_report_begin and dwfl_report_end. The libdwfl.h comments lead me to believe this is all that is necessary to remove all old modules and report only new modules. I plan to switch to dwfl_report_begin_add later on and only report modules that have changed. I got an assertion failure at the dwfl_report_end stage /home/yyz/npremji/mainworkspace/frysk/frysk-imports/elfutils/libdwfl/dwfl_module.c:249: dwfl_report_end: Assertion `i == dwfl->nmodules' failed. Looking at the dwfl_module.c file I see that dwfl_report_begin calls dwfl_report_begin_add, which clears all the modules. I thought that this function was supposed to preserver all the old modules? Also how would I go about removing single modules in an updating scenario? i.e. is there a dwfl_report_remove_module function to link with dwfl_report_begin_add? Thank you, Nurdin. From roland@redhat.com Mon Jul 16 20:41:00 2007 From: roland@redhat.com (Roland McGrath) Date: Mon, 16 Jul 2007 20:41:00 -0000 Subject: Elfutils module reporting In-Reply-To: Nurdin Premji's message of Monday, 16 July 2007 16:05:10 -0400 <469BCF76.50103@redhat.com> Message-ID: <20070716204031.42CC84D05BE@magilla.localdomain> The expected pattern is that you do: dwfl_report_begin dwfl_report_foo all modules that are in the address space now dwfl_report_end i.e., just like with a fresh Dwfl, but dwfl_report_begin instead of dwfl_begin. This preserves the existing data structures for modules that haven't changed since before dwfl_report_begin, and removes any old modules that you didn't report again. dwfl_report_begin_add is intended for something like gdb's add-symbol-file, where you are always just adding one new thing as opposed to re-synch'ing to the new set of mappings after they've changed. It's just a shorthand and mild optimization for re-reporting all the existing modules after dwfl_report_begin. I could add something like a dwfl_report_remove to de-report a reported module in a reporting loop (which after dwfl_report_begin_add would be equivalent to removing the preexisting module). But I'd rather exercise the interface as it stands a bit more before deciding to add a microoptimization. > I got an assertion failure at the dwfl_report_end stage > /home/yyz/npremji/mainworkspace/frysk/frysk-imports/elfutils/libdwfl/dwfl_module.c:249: > dwfl_report_end: Assertion `i == dwfl->nmodules' failed. Please send me a small C test program to reproduce this bug. Thanks, Roland From npremji@redhat.com Mon Jul 16 22:00:00 2007 From: npremji@redhat.com (Nurdin Premji) Date: Mon, 16 Jul 2007 22:00:00 -0000 Subject: Elfutils module reporting In-Reply-To: <20070716204031.42CC84D05BE@magilla.localdomain> References: <20070716204031.42CC84D05BE@magilla.localdomain> Message-ID: <469BEA6A.606@redhat.com> Roland McGrath wrote: > The expected pattern is that you do: > > dwfl_report_begin > dwfl_report_foo all modules that are in the address space now > dwfl_report_end > > i.e., just like with a fresh Dwfl, but dwfl_report_begin instead of dwfl_begin. > This preserves the existing data structures for modules that haven't > changed since before dwfl_report_begin, and removes any old modules that > you didn't report again. > > dwfl_report_begin_add is intended for something like gdb's add-symbol-file, > where you are always just adding one new thing as opposed to re-synch'ing > to the new set of mappings after they've changed. It's just a shorthand > and mild optimization for re-reporting all the existing modules after > dwfl_report_begin. > > I could add something like a dwfl_report_remove to de-report a reported > module in a reporting loop (which after dwfl_report_begin_add would be > equivalent to removing the preexisting module). But I'd rather exercise > the interface as it stands a bit more before deciding to add a > microoptimization. > > >> I got an assertion failure at the dwfl_report_end stage >> /home/yyz/npremji/mainworkspace/frysk/frysk-imports/elfutils/libdwfl/dwfl_module.c:249: >> dwfl_report_end: Assertion `i == dwfl->nmodules' failed. >> > > Please send me a small C test program to reproduce this bug. > > > Thanks, > Roland > Try this. It was tested against elfutils 0.128 in fedora 7. -------------- next part -------------- A non-text attachment was scrubbed... Name: dwfltest.c Type: text/x-csrc Size: 620 bytes Desc: not available URL: From roland@redhat.com Mon Jul 16 22:25:00 2007 From: roland@redhat.com (Roland McGrath) Date: Mon, 16 Jul 2007 22:25:00 -0000 Subject: Elfutils module reporting In-Reply-To: Nurdin Premji's message of Monday, 16 July 2007 18:00:10 -0400 <469BEA6A.606@redhat.com> Message-ID: <20070716222459.39D534D05CF@magilla.localdomain> I knew there was a reason I wanted a user! ;-) The reporting interface has never really been used with updates before. It's a one-line fix. --- libdwfl/dwfl_module.c 16e7ba3c4f28363c68c66975b4a123da1383e52a +++ libdwfl/dwfl_module.c dbf8292265056d2e7302f58f09e72dcdac51cf8a @@ -149,6 +149,7 @@ dwfl_report_module (Dwfl *dwfl, const ch m->next = *tailp; m->gc = false; *tailp = m; + ++dwfl->nmodules; return m; } From pmuldoon@redhat.com Tue Jul 17 15:43:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 17 Jul 2007 15:43:00 -0000 Subject: Leaving visible breakpoints in memory/core (Was: Breakpoint stepping) In-Reply-To: <1184601441.3628.58.camel@dijkstra.wildebeest.org> References: <20070712202339.A4D064D0489@magilla.localdomain> <1184601441.3628.58.camel@dijkstra.wildebeest.org> Message-ID: <469CE381.8000705@redhat.com> Mark Wielaard wrote: > On Thu, 2007-07-12 at 13:23 -0700, Roland McGrath wrote: > >> For a nondestructive dump, you also have the option of editting the memory >> as you copy it. >> > > Yes, that is the plan for bug #4761 (Task Memory view without inserted > breakpoints showing). There will be a getMemory() view that shows the > original bytes as found in the process (with anything frysk-core might > have added to it for things like breakpointing filtered out) and a > getRawMemory() that gives the raw bytes as manipulated by frysk-core. > Mark Some questions thoughts: How is this going to be implemented in the task? Are you planning on extending the abstract class Task with a getRawMemory()? If so, what does that mean for an implementing core file task? In the corefile task (dead/LinuxTask.java) are getMemory() and getRawMemory() returning the same ByteBuffer (CorefileByteBuffer) instance? Is this too live process specific and should be implemented some other way? Regards Phil From pmuldoon@redhat.com Tue Jul 17 15:47:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 17 Jul 2007 15:47:00 -0000 Subject: Leaving visible breakpoints in memory/core (Was: Breakpoint stepping) In-Reply-To: <1184601180.3628.53.camel@dijkstra.wildebeest.org> References: <20070712024947.9F7354D0489@magilla.localdomain> <4696398B.6040404@redhat.com> <1184601180.3628.53.camel@dijkstra.wildebeest.org> Message-ID: <469CE468.7030006@redhat.com> Mark Wielaard wrote: > But if you really wanted to then you could at least get the breakpoints > instructions that frysk-core inserted from BreakpointAddresses (which I > will soon extend with a handy getAllAdresses() method for fixing bug > #4761), and then you can get the actual breakpoint instruction bytes > used from the relevant Isa getBreakpointInstruction(). This is probably > too low level though. And since you cannot guarantee that the created > core file is read back through frysk (someone could be using gdb!) I > don't know where you would actually put this information or how you > would make all consumers know about both the original bytes and the > breakpoint instructions in the image. > What's the argument about just dumping the task's memory as is, with all breakpoints there? A corefile is a representation of that process and it's thread as it is at that time ... And besides, this is only addressing a tiny corner case of someone running fcore on a process that is being debugged with Frysk at that time. I can't think of a scenario why I would do that. Can you? If they were debugging with GDB and fcore was run on that process, the included core image would have all the break point information. It seems like a lot of work for a very small edge case? Regards Phil From pmuldoon@redhat.com Tue Jul 17 15:54:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 17 Jul 2007 15:54:00 -0000 Subject: frysk-cvs patch tuning Message-ID: <469CE638.60900@redhat.com> Is it possible to tune frysk-cvs mailing list to include patches, and not links to patches? I find this list very useful, and read the list/patches everyday. but I hate the mass clicking on links. It would make reply-to questions on some code more context-friendly if the patch part is included in the email. Is it possible to tune the list to include patches instead of links? What's the consensus on doing this? And if the above two come back positive, what person needs to be contacted to make it happen? Regards Phil From cagney@redhat.com Tue Jul 17 16:19:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 17 Jul 2007 16:19:00 -0000 Subject: [Fwd: frysk-imports ./ChangeLog ./Makefile.am ./Chan ...] Message-ID: <469CEC21.60706@redhat.com> As you can probably tell by the lack of a changelog, this wasn't the intent. A <> in the wrong directory :-( I think I've now managed to revert it. sigh, Andrew -------------- next part -------------- An embedded message was scrubbed... From: cagney@sourceware.org Subject: frysk-imports ./ChangeLog ./Makefile.am ./Chan ... Date: 17 Jul 2007 16:15:37 -0000 Size: 52432 URL: From mark@klomp.org Tue Jul 17 17:06:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 17 Jul 2007 17:06:00 -0000 Subject: Leaving visible breakpoints in memory/core (Was: Breakpoint stepping) In-Reply-To: <469CE381.8000705@redhat.com> References: <20070712202339.A4D064D0489@magilla.localdomain> <1184601441.3628.58.camel@dijkstra.wildebeest.org> <469CE381.8000705@redhat.com> Message-ID: <1184691997.3663.49.camel@dijkstra.wildebeest.org> Hi Phil, On Tue, 2007-07-17 at 10:42 -0500, Phil Muldoon wrote: > How is this going to be implemented in the task? Are you planning on > extending the abstract class Task with a getRawMemory()? Yes. With an default implementation: /** * Returns the memory as seen by frysk-core. That includes things like * inserted breakpoint instructions bytes which are filtered out by * getMemory() (which is what you normally want unless * you are interested in frysk-core specifics). *

* Default implementation calls getMemory(), need to be * overriden by subclasses for which the raw memory view and the * logical memory view are different. */ public ByteBuffer getRawMemory() { return getMemory(); } > If so, what does that mean for an implementing core file task? In the > corefile task (dead/LinuxTask.java) are getMemory() and getRawMemory() > returning the same ByteBuffer (CorefileByteBuffer) instance? Yes, you get the support for free. > Is this too live process specific and should be implemented some other way? No, I think the generic implementation is the way to go so the user doesn't have to worry about what specific implementation instance of Task they are using. But please do comment when I post the patch and you feel it should be done differently. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From swagiaal@redhat.com Tue Jul 17 17:07:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Tue, 17 Jul 2007 17:07:00 -0000 Subject: Dwarf expertise needed In-Reply-To: <20070619213109.8D9BB4D05D3@magilla.localdomain> References: <20070619213109.8D9BB4D05D3@magilla.localdomain> Message-ID: <469CF739.7000706@redhat.com> Roland McGrath wrote: >> Okay it sounds like I missunderstood what addrdie does. I guess what I >> am trying to do is find the narrowest scope which contains the given pc. >> Is there a way to get all dies whos ranges contain the pc maybe ? The >> problem I am trying to solve is given a pc find the inlined/concrete >> function that contains it. >> > > This is what dwarf_getscopes is for. > Okay so I have been looking at dwarf_getscopes.c trying to find a fix for https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230235. Now i can fudge the function pc_record to return the results that I am expecting but it looks like it is trying to do something different from what I understand when it comes to inlined functions. It looks like getscopes is trying to return the scopes from narrowest up to the scope before the concrete inlined instance then the abstract definition of the concrete instance, and then the scopes that contain that. Is this a correct understanding of the code ? What I am expecting it to return is the the scopes from narrowest to and including the scope corresponding to the concrete inlined instance, then the function within which it has been inlined and the scopes containing that; as per the dwarf spec. Is this a correct understanding of what the function /should/ do ? And should I fix the function, write a parallel one that does what i want, or is there another code pathway to get it ? Cheers, Sami Wagiaalla From mark@klomp.org Tue Jul 17 17:08:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 17 Jul 2007 17:08:00 -0000 Subject: Leaving visible breakpoints in memory/core (Was: Breakpoint stepping) In-Reply-To: <469CE468.7030006@redhat.com> References: <20070712024947.9F7354D0489@magilla.localdomain> <4696398B.6040404@redhat.com> <1184601180.3628.53.camel@dijkstra.wildebeest.org> <469CE468.7030006@redhat.com> Message-ID: <1184692072.3663.52.camel@dijkstra.wildebeest.org> Hi Phil, On Tue, 2007-07-17 at 10:46 -0500, Phil Muldoon wrote: > Mark Wielaard wrote: > What's the argument about just dumping the task's memory as is, with all > breakpoints there? A corefile is a representation of that process and > it's thread as it is at that time ... Because you don't know why/what those breakpoint instructions are doing there. Since none of the observer logic is saved together with the core file you wouldn't know why and what that breakpoint instruction is doing there. Worse, you don't even know what is underneath it. > And besides, this is only addressing a tiny corner case of someone > running fcore on a process that is being debugged with Frysk at that > time. I can't think of a scenario why I would do that. Can you? Yes. The scenario using fcore I have in mind is one where a user has reported some behavior that cannot easily be explained and that only happens in some production environment. You might have an idea why it might happen but need proof and would need to inspect the actual state of the process more closely when it happens. But the user doesn't want to hand over the whole running process to you so you can stop it completely. So you write a little frysk-core based program that triggers under certain conditions (possibly involving breakpoints) and that generates a core file of the full process state but that you then want to inspect offline (maybe even by a third person with something like gdb). You want the fcore generated file to represent the state of the process as if it was pristine, not with lingering low level breakpoint or other frysk artifacts in it so you know what the actual code was doing. > If they > were debugging with GDB and fcore was run on that process, the included > core image would have all the break point information. Yes, although in practise this currently doesn't work since our ptrace based implementation won't let two different processes attach to the same process. > It seems like a lot of work for a very small edge case? But it isn't just for fcore. And as you showed above maybe fcore should have an option to select whether or not to dump logical memory or raw memory. It is mainly used for other observers inspecting the task. We don't want to retract all low level breakpoints when one task stops (so other tasks can keep running and possible hit that or another low level breakpoint). But when looking at the actual memory dump we want it to show what would actually be there. The user is most likely interested in the actual instruction at that point, not in the frysk inserted breakpoint instruction. This makes the higher level tasks not need to worry how the actual implementation of some lower level task actually works. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cagney@redhat.com Tue Jul 17 18:20:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 17 Jul 2007 18:20:00 -0000 Subject: frysk ui meeting 2007-07-18 9:30 US east coast time Message-ID: <469D089A.5050002@redhat.com> (contact me for dial in info, in North America it's a free call) This week we're going to look at the "display" stuff adam has been working on. In particular, what it is and how it can be used :-) All welcome. Andrew From cagney@redhat.com Tue Jul 17 18:36:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 17 Jul 2007 18:36:00 -0000 Subject: re-split all frysk-import's CNI code into frysk-sys In-Reply-To: <46963363.7030500@redhat.com> References: <46963363.7030500@redhat.com> Message-ID: <469D0C27.80807@redhat.com> (after a false start) I've checked this in; take care. Andrew Cagney wrote: > I'm going to investigate moving all of the cni (bindings) code in > frysk-imports moving it into frysk-sys. That would be the lib/ frysk/ > and inua/ directories. > > At present working on those bindings is a pta as it is too easy to > trigger an unnecessary re-build / re-conf when modifying a binding. > This will also open the way for making parts of frysk-imports, such > libunwind and elfutils optional. > > http://sourceware.org/bugzilla/show_bug.cgi?id=4784 From cagney@redhat.com Tue Jul 17 18:43:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 17 Jul 2007 18:43:00 -0000 Subject: frysk-cvs patch tuning In-Reply-To: <469CE638.60900@redhat.com> References: <469CE638.60900@redhat.com> Message-ID: <469D0DE7.5020409@redhat.com> Phil Muldoon wrote: > Is it possible to tune frysk-cvs mailing list to include patches, and > not links to patches? I find this list very useful, and read the > list/patches everyday. but I hate the mass clicking on links. It would > make reply-to questions on some code more context-friendly if the > patch part is included in the email. > Well, if we switched from CVS then this would be a non-issue. I wonder if that is a better solution. (Would certainly have made my life this morning easier :-) > Is it possible to tune the list to include patches instead of links? > The file CVSROOT/loginfo (from memory) would need to be changed. > What's the consensus on doing this? > > And if the above two come back positive, what person needs to be > contacted to make it happen? Probably me :-) > > Regards > > Phil From cagney@redhat.com Tue Jul 17 18:51:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 17 Jul 2007 18:51:00 -0000 Subject: consolidate lib.elf and lib.dw bindings into a single lib.eu (elfutils) package In-Reply-To: <469782FC.5060209@redhat.com> References: <469642CF.3010007@redhat.com> <469782FC.5060209@redhat.com> Message-ID: <469D0FD3.1090809@redhat.com> Andrew Cagney wrote: > I thought of a better name; put everything in lib.elf :-) The final, and somewhat arbitrary name, is lib.dwfl; it reflects how frysk typically uses that code, start with a Dwfl and work down. The only exception is the code directly manipulating core files. Andrew > > Andrew Cagney wrote: >> Hello, >> >> At present the lib.dw and lib.elf bindings share things via some >> public interfaces and fields. Given their very tightly coupled >> nature I intend consolidating these bindings (lib.elf and lib.eu) >> into a single (lib.eu) package. (For want of a better name :-) >> >> http://sourceware.org/bugzilla/show_bug.cgi?id=4786 >> >> Andrew >> > From mcvet@redhat.com Tue Jul 17 20:25:00 2007 From: mcvet@redhat.com (Mike Cvet) Date: Tue, 17 Jul 2007 20:25:00 -0000 Subject: uslurp change Message-ID: <469D25B6.5040804@redhat.com> Code in frysk-sys/proc/cni/slurp.cxx : uslurp which previously was: int fd = ::open (file, O_RDONLY); if (errno != 0) { ::free(buf); return NULL; Has been changed to replicate behaviour seen in FileDescriptor.cxx where, if the maximum number of file descriptors has been reached, the garbage collector will be continually prodded until some descriptors get freed up. - Mike From pmuldoon@redhat.com Tue Jul 17 20:32:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 17 Jul 2007 20:32:00 -0000 Subject: uslurp change In-Reply-To: <469D25B6.5040804@redhat.com> References: <469D25B6.5040804@redhat.com> Message-ID: <469D275C.9010108@redhat.com> Mike Cvet wrote: > Code in frysk-sys/proc/cni/slurp.cxx : uslurp which previously was: > > int fd = ::open (file, O_RDONLY); > if (errno != 0) { > ::free(buf); > return NULL; > > Has been changed to replicate behaviour seen in FileDescriptor.cxx > where, if the maximum number of file descriptors has been reached, the > garbage collector will be continually prodded until some descriptors > get freed up. > Mike uslurp is a "special case" function for /proc/$$/maps which can be large. It does the realloc dance on multiple 4k page reads while slurp just reads one page from /proc. The older slurp still does the vast majority of reads from /proc, so this optimization will be needed there to. I cannot think of a reason why I just did not replace uslurp with slurp many moons ago, but thinking about it, it probably should. Regards Phil From mark@klomp.org Wed Jul 18 07:52:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 18 Jul 2007 07:52:00 -0000 Subject: frysk-cvs patch tuning In-Reply-To: <469D0DE7.5020409@redhat.com> References: <469CE638.60900@redhat.com> <469D0DE7.5020409@redhat.com> Message-ID: <1184745116.3652.13.camel@dijkstra.wildebeest.org> Hi, On Tue, 2007-07-17 at 14:43 -0400, Andrew Cagney wrote: > Phil Muldoon wrote: > > Is it possible to tune frysk-cvs mailing list to include patches, and > > not links to patches? I find this list very useful, and read the > > list/patches everyday. but I hate the mass clicking on links. It would > > make reply-to questions on some code more context-friendly if the > > patch part is included in the email. Yes, that would be nice. I also try to click through on most changes and replying to such messages is indeed a bit of a pain. I now just post my patches to the list since I noticed I get more response/reviews that way. And because I like to double check what I commit beforehand and because I like to explain why I am making particular changes (that last one isn't something you get from frysk-commit always since the commit message often just explains what was changed, not why). > > Is it possible to tune the list to include patches instead of links? > > > The file CVSROOT/loginfo (from memory) would need to be changed. I see that file refers to /usr/sourceware/bin/commit_prep do you have access to that script to see what kind of arguments it takes? Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Wed Jul 18 08:01:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 18 Jul 2007 08:01:00 -0000 Subject: frysk-imports/tests Makefile.am ChangeLog In-Reply-To: <20070717205605.10360.qmail@sourceware.org> References: <20070717205605.10360.qmail@sourceware.org> Message-ID: <1184745671.3652.16.camel@dijkstra.wildebeest.org> Hi Nurdin, On Tue, 2007-07-17 at 20:56 +0000, npremji@sourceware.org wrote: > Log message: > frysk-imports/tests/CL > * Makefile.am (systests_XFAIL_PROGRAMS): Removed frysk4796/dwfltest. > (system_PASS_PROGRAMS): Added frysk4796/dwfltest. You also need to add the in-tree libelf include path explicitly, otherwise you pick up the wrong gelf.h file (or in my case, on a machine without libelf-devel installed you won't find gelf.h at all): 2007-07-18 Mark Wielaard * Makefile.am (frysk4796_dwfltest_CFLAGS): Add -I$(top_srcdir)/elfutils/libelf. Cheers, Mark diff -u -r1.114 Makefile.am --- Makefile.am 17 Jul 2007 20:56:05 -0000 1.114 +++ Makefile.am 18 Jul 2007 08:00:30 -0000 @@ -513,7 +513,7 @@ chmod a+x $@ frysk4796_dwfltest_CFLAGS = -I$(top_srcdir)/elfutils/libdwfl \ --I$(top_srcdir)/elfutils/libdw +-I$(top_srcdir)/elfutils/libdw -I$(top_srcdir)/elfutils/libelf frysk4796_dwfltest_LDADD = -ldl $(top_builddir)/elfutils/libdw/libdw.a \ $(top_builddir)/elfutils/libebl/libebl.a \ $(top_builddir)/elfutils/libelf/libelf.a -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Wed Jul 18 08:40:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 18 Jul 2007 08:40:00 -0000 Subject: frysk ui meeting 2007-07-18 9:30 US east coast time In-Reply-To: <469D089A.5050002@redhat.com> References: <469D089A.5050002@redhat.com> Message-ID: <1184748020.3652.26.camel@dijkstra.wildebeest.org> Hi, So that is at 13:30 UTC, 15:30 Amsterdam, 06:30 San Francisco On Tue, 2007-07-17 at 14:21 -0400, Andrew Cagney wrote: > (contact me for dial in info, in North America it's a free call) > > This week we're going to look at the "display" stuff adam has been > working on. In particular, what it is and how it can be used :-) I have setup a vnc server with Fedora 7 and a cvs build from this morning. If people want anything else on the machine to demo please let me know (mjw in #frysk on irc.gimp.net). Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From roland@redhat.com Wed Jul 18 09:03:00 2007 From: roland@redhat.com (Roland McGrath) Date: Wed, 18 Jul 2007 09:03:00 -0000 Subject: Dwarf expertise needed In-Reply-To: Sami Wagiaalla's message of Tuesday, 17 July 2007 13:07:05 -0400 <469CF739.7000706@redhat.com> Message-ID: <20070718090247.A712B4D05CF@magilla.localdomain> > Okay so I have been looking at dwarf_getscopes.c trying to find a fix > for https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230235. I have not had my head in that particular code in quite some time, and I have not yet looked at all what's going on in Stan's test case. Before any bugs were reported, I already knew there were some issues with the function from the time I wrote it, which relate to the distinction you are asking about. > It looks like getscopes is trying to return the scopes from narrowest up > to the scope before the concrete inlined instance then the abstract > definition of the concrete instance, and then the scopes that contain > that. Is this a correct understanding of the code ? > > What I am expecting it to return is the the scopes from narrowest to and > including the scope corresponding to the concrete inlined instance, then > the function within which it has been inlined and the scopes containing > that; as per the dwarf spec. Is this a correct understanding of what the > function /should/ do ? And should I fix the function, write a parallel > one that does what i want, or is there another code pathway to get it ? I don't know why you call that "as per the dwarf spec". (The spec says what the format means, not what any function does.) The chief purpose of dwarf_getscopes is to get the lexical scope DIEs containing the PC, from innermost to outermost. This means the literal lexical scope, i.e. for C-like syntax { } groups in the text. In the case of a PC inside a concrete inlined instance, it's still the literal lexical scope of that function. The lexical scope as expressed by the generic DWARF structure corresponds exactly to the identifier scope rules of a simple language like C. So this is what you need to pass to dwarf_getscopevar to resolve a C identifier at the scope of this PC. Take the example: static int cu_var = 1; inline int a_fn (int a_arg) { static int a_var = 1; PC1--> return ++a_var + a_arg + ++cu_var; } int b_fn () { static int b_var = 2; int c_fn () { static int c_var = 3; c_var += a_fn (b_var++); PC2--> return c_var; } return c_fn (); } The DWARF structure here will look like (much omitted): compile_unit "foo.c" variable "cu_var" subprogram "a_fn" <-- abstract inlined instance formal_parameter "a_arg" ^ <-- type | ` variable "a_var" | | type | | location | | subprogram "b_fn" | | variable "b_var" | | subprogram "c_fn" | | frame_base | | variable "c_var" | | inlined_subroutine -' | <-- concrete low_pc PC1 | inlined formal_parameter -' instance location (My pretty lines indicate DIEs with an abstract_origin ref to another DIE.) For PC2, dwarf_getscopes should yield [, , ]. For PC1, dwarf_getscopes should yield [, , ]. is physically inside , but it is lexically where is. In the scope context of PC1 (), "a_var" is visible and "cu_var" is visible, but "b_var" and "c_var" are not. has its own DIE for "a_arg" because its DW_AT_location details are specific to the concrete inlined instance. (That one a partial DIE, it has location but refers to its abstract counterpart for invariant attributes like type.) But elides the "a_var" DIE entirely because it is the same for all possible concrete instances of . This is why appears as a scope outside , or rather, it's why appears as a scope inside . is not really a lexical scope at all, just a physical instance. For naive uses like dwarf_getscopevar, it works fine to treat as a scope inside . But any sophisticated caller needs to check each "scope" DIE in the array for actually being an inlined_subroutine, meaning that its containing scope is not really a different scope, but the two together describe one lexical scope. e.g., something visualizing scopes and showing all the identifiers defined in each scope would need to grok this. Now imagine "a_var" is called "b_var" and "cu_var" is called "c_var", so it really matters which scope you mean when you ask for "c_var" by name. You can see why it's vital that for "identifiers visible at the PC1 context", you not be looking at a list that includes or . So that covers what "return scopes containing" should mean, and what dwarf_getscopes is intended to do in the interface it has now. Note that this is only the beginning of the story for mapping an identifier in a scope to a DIE in general, though it's the end of the story for C. In a language like C++, the literal lexical scope list from dwarf_getscopes feeds into a language-specific identifier scope engine that knows that the DIE for a method definition is a scope that can see identifiers from its class as well as from its lexically containing scope (e.g. the CU)--which is different from its class DIE being its lexical container, which it may or may not be. Now, the trouble with this highly sensical picture comes when you get to the nitty-gritty of making use of the DIEs you found in those scopes. It turns out that sometimes you need to know something about the physical structure of the code, not just the semantic lexical scope. Say you're at ye olde PC1 and you want to see "a_arg". Great, it's in . Now this bugger's location attribute says {DW_OP_fbreg(+24)}. Well, whose frame_base did he mean? He meant 's. But I just convinced you that better be nowhere in your handy list of DIEs to consult! If you take all this and contemplate all the permutations of inlining and nested functions there could be, it's rather mindbending. My mind was bent in this way while writing the function, and I still kept thinking it could be done with the simple interface yielding one ordered list of DIEs. In that frame of mind, I wrote and tweaked and rewrote to whatever it actually does now, and goodness knows what exactly that came out to be. After a libdw with this interface got released, I realized it just can't do it all for all cases with that interface. I had other fish to fry and let it lie, but knew I would have to revisit it and get it all clear at some point. Contemplating it now, I don't think it is really so quite confusing what's required, at least for frame_base. I probably need to think more about the nested function cases, and might confuse myself again doing it. I also haven't thought of anything other than frame_base that a dwarf_getscopes caller might need from a physically relevant but lexically disjoint DIE. Something else I'm overlooking might have different requirements. To get the right frame_base, I think a straightforward change of the getscopes interface can cover it. As well as the array of lexical scope DIEs, it would yield a parallel array of Dwarf_Die pointers. Each scope[i] corresponds to base_scope[i]. Locations from scope[i] are resolved in the physical context of base_scope[i]. For simple cases, scope[i]==base_scope[i]. When scope[i] is an inlined_subroutine, base_scope[i] is the containing subprogram that has the actual code. So, in all cases, base_scope[i] is where you need to look for a frame_base attribute when scope[i] leads you to a location that uses frame_base. But I'd like to try to think of other things than frame_base one might need, and think through the nested function cases, before deciding what exact change the interface should get. Right now, if your test cases do not require the frame_base attribute, then we can just work on fixing any bugs in the implementation of the current definition of the dwarf_getscopes interface as I described it above. dwarf_getscopes has always been for the source-level semantic view of lexical identifier scope. For other purposes, you might instead be looking for the physical structural view of the compiled code. For example, if you are displaying the running code in an inlined instance and want to visualize "this code inlined into here", or are synthesizing fictional call frames for a semantic backtrace including inlined calls. (If you are only displaying the source location of the caller, you have the call_{file,line,column} attributes at hand and don't need the caller's DIE at all.) dwarf_getscopes_die does exactly this, though its name and comments would lead you to think it acts like dwarf_getscopes when given a DIE that is part of a concrete inlined instance tree. (That's what it probably should do, and there should be a different call for the simple structural visitor.) So with 0.128 code, you can use dwarf_getscopes on a PC, then take a scope[i] of interest such as an inlined_subroutine DIE, and pass it to dwarf_getscopes_die to see its caller's scope context. Thanks, Roland From swagiaal@redhat.com Wed Jul 18 15:38:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Wed, 18 Jul 2007 15:38:00 -0000 Subject: Dwarf expertise needed In-Reply-To: <20070718090247.A712B4D05CF@magilla.localdomain> References: <20070718090247.A712B4D05CF@magilla.localdomain> Message-ID: <469E33E1.7080909@redhat.com> Roland, First of all thank you for the thorough reply. I now see issues that I have not seen before. Roland McGrath wrote: >> What I am expecting it to return is the the scopes from narrowest to and >> including the scope corresponding to the concrete inlined instance, then >> the function within which it has been inlined and the scopes containing >> that; as per the dwarf spec. Is this a correct understanding of what the >> function /should/ do ? And should I fix the function, write a parallel >> one that does what i want, or is there another code pathway to get it ? >> > > I don't know why you call that "as per the dwarf spec". (The spec says > what the format means, not what any function does.) > I just meant to say "scope" in the dwarf spec sense, as opposed to lexical scope. [...] > Contemplating it now, I don't think it is really so quite confusing what's > required, at least for frame_base. I probably need to think more about the > nested function cases, and might confuse myself again doing it. I also > haven't thought of anything other than frame_base that a dwarf_getscopes > caller might need from a physically relevant but lexically disjoint DIE. > Something else I'm overlooking might have different requirements. To get > the right frame_base, I think a straightforward change of the getscopes > interface can cover it. As well as the array of lexical scope DIEs, it > would yield a parallel array of Dwarf_Die pointers. Each scope[i] > corresponds to base_scope[i]. Locations from scope[i] are resolved in the > physical context of base_scope[i]. For simple cases, scope[i]==base_scope[i]. > When scope[i] is an inlined_subroutine, base_scope[i] is the containing > subprogram that has the actual code. So, in all cases, base_scope[i] is > where you need to look for a frame_base attribute when scope[i] leads you to > a location that uses frame_base. > > But I'd like to try to think of other things than frame_base one might > need, and think through the nested function cases, before deciding what > exact change the interface should get. > That is cool. If it turns out that frame_base is the only instance then how about a function get_framebase that is smart enough to figure out where the correct frame base is. That way you help the client not make that mistake. Or get_* for each attribute that needs the abstract instance of the function. > Right now, if your test cases do not require the frame_base attribute, > then we can just work on fixing any bugs in the implementation of the > current definition of the dwarf_getscopes interface as I described it above. > > dwarf_getscopes has always been for the source-level semantic view of > lexical identifier scope. For other purposes, you might instead be > looking for the physical structural view of the compiled code. For > example, if you are displaying the running code in an inlined instance > and want to visualize "this code inlined into here", or are synthesizing > fictional call frames for a semantic backtrace including inlined calls. > (If you are only displaying the source location of the caller, you have > the call_{file,line,column} attributes at hand and don't need the > caller's DIE at all.) dwarf_getscopes_die does exactly this, though its > name and comments would lead you to think it acts like dwarf_getscopes > when given a DIE that is part of a concrete inlined instance tree. > (That's what it probably should do, and there should be a different call > for the simple structural visitor.) So with 0.128 code, you can use > dwarf_getscopes on a PC, then take a scope[i] of interest such as an > inlined_subroutine DIE, and pass it to dwarf_getscopes_die to see its > caller's scope context. > That will do, although I think there might be a bug there :(. Let me double check. From ajocksch@redhat.com Wed Jul 18 15:54:00 2007 From: ajocksch@redhat.com (Adam Jocksch) Date: Wed, 18 Jul 2007 15:54:00 -0000 Subject: [Fwd: Displays in the GUI] Message-ID: <469E3792.9030707@redhat.com> This is the email I sent out earlier with some mockups of how to add displays to the source window. Arrays and data structures could be added to this by making complex types appear as a tree in the list. -------------- next part -------------- An embedded message was scrubbed... From: Adam Jocksch Subject: Displays in the GUI Date: Tue, 03 Jul 2007 11:42:30 -0600 Size: 116303 URL: From mcvet@redhat.com Wed Jul 18 18:25:00 2007 From: mcvet@redhat.com (Mike Cvet) Date: Wed, 18 Jul 2007 18:25:00 -0000 Subject: uslurp change In-Reply-To: <469D275C.9010108@redhat.com> References: <469D25B6.5040804@redhat.com> <469D275C.9010108@redhat.com> Message-ID: <469E5AFB.2030802@redhat.com> Phil Muldoon wrote: > uslurp is a "special case" function for /proc/$$/maps which can be > large. It does the realloc dance on multiple 4k page reads while slurp > just reads one page from /proc. The older slurp still does the vast > majority of reads from /proc, so this optimization will be needed > there to. I cannot think of a reason why I just did not replace uslurp > with slurp many moons ago, but thinking about it, it probably should. > The update has been added to slurp() and slurp_thread() as well, through a new method in Errno.cxx called tryOpen(). - Mike From cagney@redhat.com Wed Jul 18 19:18:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 18 Jul 2007 19:18:00 -0000 Subject: new command fexe Message-ID: <469E678F.1020101@redhat.com> This is from the man page: $ cp /bin/bash /tmp/sh $ PS1=??sh$ ?? /tmp/sh sh$ fexe $$ /tmp/sh sh$ rm /tmp/sh sh$ fexe -v $$ 1234 null /tmp/sh (deleted) From roland@redhat.com Wed Jul 18 22:43:00 2007 From: roland@redhat.com (Roland McGrath) Date: Wed, 18 Jul 2007 22:43:00 -0000 Subject: Dwarf expertise needed In-Reply-To: Sami Wagiaalla's message of Wednesday, 18 July 2007 11:38:09 -0400 <469E33E1.7080909@redhat.com> Message-ID: <20070718224349.165984D05CF@magilla.localdomain> > First of all thank you for the thorough reply. I now see issues that I > have not seen before. I think I'll have that on my tombstone. ;-) > If it turns out that frame_base is the only instance then how about a > function get_framebase that is smart enough to figure out where the > correct frame base is. That way you help the client not make that > mistake. Or get_* for each attribute that needs the abstract instance of > the function. For attributes in general it's easy, you just use dwarf_attr_integrate. For elided children I don't have a handy helper yet, but it is straightforward to follow the abstract_origin reference and go from there. The frame_base case is on the other side of exactly the distinction I pointed out. It has nothing to do with the abstract instance, and only to do with the physical parent of the particular concrete instance. Figuring it out requires a tree walk to find the parent. It makes sense to fetch that as part of the same operation as something like getscopes primarily because that same tree walk is already being done. I've imagined there might in future be some libdw optimizations that would preserve some back-pointers to make it efficient to go up the tree, though I certainly haven't figured out all the details of that. So it might make sense to use a separate call for this with the expectation that its expensive repeat of the tree walk will be optimized in the future, but I'm not quite sure. I'd still like to contemplate the potential related cases a bit more. > That will do, although I think there might be a bug there :(. Let me > double check. There is certainly a bug hit by Stan's test case, since it gets an error. Thanks, Roland From scox@redhat.com Thu Jul 19 04:13:00 2007 From: scox@redhat.com (Stan Cox) Date: Thu, 19 Jul 2007 04:13:00 -0000 Subject: fhpd commands extended to include displays In-Reply-To: <469B91E6.4050507@redhat.com> References: <469B91E6.4050507@redhat.com> Message-ID: <1184818091.3094.2.camel@multics.rdu.redhat.com> > Do we want to have somewhere to document the extensions to the hpd spec > that we decide to implement in frysk? (i.e. the display command). It is possible to add some brief help via UserHelp.java From mark@klomp.org Thu Jul 19 08:37:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Thu, 19 Jul 2007 08:37:00 -0000 Subject: new command fexe In-Reply-To: <469E678F.1020101@redhat.com> References: <469E678F.1020101@redhat.com> Message-ID: <1184834265.3629.21.camel@dijkstra.wildebeest.org> Hi Andrew, On Wed, 2007-07-18 at 15:18 -0400, Andrew Cagney wrote: > This is from the man page: > > $ cp /bin/bash /tmp/sh > $ PS1=?sh$ ? /tmp/sh > sh$ fexe $$ > /tmp/sh > sh$ rm /tmp/sh > sh$ fexe -v $$ > 1234 null /tmp/sh (deleted) Can you use this to show that soft link bug a softlink contains a \0 character in it? It would be good to have a showcase of that so we can report it upstream. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From npremji@redhat.com Thu Jul 19 14:23:00 2007 From: npremji@redhat.com (Nurdin Premji) Date: Thu, 19 Jul 2007 14:23:00 -0000 Subject: Fhpd disassemble command Message-ID: <469F73D5.40509@redhat.com> The disassemble command has just been added to the fhpd, it currently disassembles the entire function surrounding the current frame address, an entire function surrounding a given address, or disassembles between a range given two addresses. The next optimization is to have it only disassemble the 5-10 lines before and after a given address, and to choose what sort of columns/information to display during the disassemble. The 5-10 line limit shouldn't be too difficult I'm wondering if there exists a java.util. LimitedList of some sort that can be restricted to have 10-20 items and when newer items are added the oldest item is automatically dropped. (So a limited queue really). Otherwise I'll build my own. I believe the line command does the same sort of stuff so I'll look there as well. So enjoy the disassembler. From swagiaal@redhat.com Thu Jul 19 15:07:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Thu, 19 Jul 2007 15:07:00 -0000 Subject: Fhpd disassemble command In-Reply-To: <469F73D5.40509@redhat.com> References: <469F73D5.40509@redhat.com> Message-ID: <469F7E40.5000209@redhat.com> Nurdin Premji wrote: > The disassemble command has just been added to the fhpd Good news!.. I will be trying i soon. From mcvet@redhat.com Thu Jul 19 15:11:00 2007 From: mcvet@redhat.com (Mike Cvet) Date: Thu, 19 Jul 2007 15:11:00 -0000 Subject: Fhpd disassemble command In-Reply-To: <469F73D5.40509@redhat.com> References: <469F73D5.40509@redhat.com> Message-ID: <469F7F35.1090109@redhat.com> Nurdin Premji wrote: > The disassemble command has just been added to the fhpd, it currently > disassembles the entire function surrounding the current frame > address, an entire function surrounding a given address, or > disassembles between a range given two addresses. I'll be using this new functionality from the Disassembler class in the SourceWindow too. - Mike From swagiaal@redhat.com Thu Jul 19 15:31:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Thu, 19 Jul 2007 15:31:00 -0000 Subject: Dwarf expertise needed In-Reply-To: <20070718224349.165984D05CF@magilla.localdomain> References: <20070718224349.165984D05CF@magilla.localdomain> Message-ID: <469F83A5.8090803@redhat.com> >> That will do, although I think there might be a bug there :(. Let me >> double check. >> > > There is certainly a bug hit by Stan's test case, since it gets an error. > So yes there is a bug, I have not checked to see if it is Stan's bug, but here it goes: This is the test case that I am using: inline void second(){ int* a = 0; a[0] = 0; <-------- pc } void first(){ second(); } int main(){ first(); return 0; } So if I try to dwarf_getscopes at pc i get 0 scopes returned. The problem is in the pc_record function from dwarf_getscopes.c: > /* Now we are in a scope that contains the concrete inlined instance. > Search it for the inline function's abstract definition. > If we don't find it, return to search the containing scope. > If we do find it, the nonzero return value will bail us out > of the postorder traversal. */ > return __libdw_visit_scopes (depth, die, &origin_match, NULL, &a); > } The problem is that if the die passed to __libdw_visit_scopes has no children, __libdw_visit_scopes returns -1 which means that pc_record returns -1 and the search aborts, and no scopes are returned. The particular childless die in this case happens to be the one corresponding to main. I can fudge it by adding some variables to main and get the following scopes: scopes[0] DW_TAG_lexical_block name: scopes[1] DW_TAG_inlined_subroutine name: second scopes[2] DW_TAG_compile_unit name: /to/scratch/swagiaal/frysks/frysk/frysk-core/frysk/pkglibdir/funit-scopes.c I have attached two of possible patches: patch1 just check for children before the call, patch2 takes the responsibility away from pc_record and relies on the later call to pc_origin in dwarf_getscopes: [...] int result = __libdw_visit_scopes (0, &cu, &pc_match, &pc_record, &a); if (result == 0 && a.scopes != NULL) result = __libdw_visit_scopes (0, &cu, &origin_match, NULL, &a); [...] I personally like patch2 better. This way you only do two searches. Thoughts ? Thanks, Sami Wagiaalla -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch1 URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch2 URL: From swagiaal@redhat.com Thu Jul 19 15:40:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Thu, 19 Jul 2007 15:40:00 -0000 Subject: Dwarf expertise needed In-Reply-To: <20070718090247.A712B4D05CF@magilla.localdomain> References: <20070718090247.A712B4D05CF@magilla.localdomain> Message-ID: <469F85DF.4050000@redhat.com> > [...] if you are displaying the running code in an inlined instance > and want to visualize "this code inlined into here", In the future we are going to do that. > or are synthesizing > fictional call frames for a semantic backtrace including inlined calls. > This is what I am currently doing :). But something else just occurred to me. The way I find a function (regular not inlined ) corresponding to a frame is I call dwarf_getscopes at frame address, then traverse up the scopes list until I hit the first DW_TAG_Subprogram. For this I will also need a physical scope list rather than a lexical one, because if a function in the list happens to be inlined between the narrowest scope and the Subprogram I will not find the reference to my Subprogram. From eteo@redhat.com Fri Jul 20 03:08:00 2007 From: eteo@redhat.com (Eugene Teo) Date: Fri, 20 Jul 2007 03:08:00 -0000 Subject: Extending Frysk to trace user-space lockings Message-ID: <46A02732.3090900@redhat.com> Hi, Is it possible to extend Frysk to trace user-space lockings? I am trying to write a tool that basically outputs the lock used and the backtrace showing who is holding on to it. I don't really have an example output that I can show, but if you have an idea to share, do let me know! Thanks, Eugene From mark@klomp.org Fri Jul 20 08:51:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Fri, 20 Jul 2007 08:51:00 -0000 Subject: Extending Frysk to trace user-space lockings In-Reply-To: <46A02732.3090900@redhat.com> References: <46A02732.3090900@redhat.com> Message-ID: <1184921481.3611.17.camel@dijkstra.wildebeest.org> Hi Eugene, On Fri, 2007-07-20 at 11:08 +0800, Eugene Teo wrote: > Is it possible to extend Frysk to trace user-space lockings? I am trying to > write a tool that basically outputs the lock used and the backtrace showing > who is holding on to it. I don't really have an example output that I can show, > but if you have an idea to share, do let me know! I am afraid I know too little about user space locking or even know how various user space locking mechanisms are implemented to give a real answer. Lets assume you are interested in pthread mutexes. Then what you can do at this point with frysk is get a simple stack trace of all threads of a process using ftrace this should include things like pthread_cond_wait() calls. This at least gives you info on whether or not threads are contending. We could build on that by extracting the mutex argument from that call and then get the owner from that (although I am not sure how standardized all this is and whether or not you are supposed to be able to get at the owner field). But that needs some creative hacking on the frysk sources to make your own specialized ftrace-pthread-mutex variant and possibly you will need the debug info for the program you are examining to munch through the stack frame, function call argument list and mutex fields. Hope some of the above rambling makes sense. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Fri Jul 20 12:02:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Fri, 20 Jul 2007 12:02:00 -0000 Subject: [patch] LogicalMemoryBuffer Message-ID: <1184932926.3611.58.camel@dijkstra.wildebeest.org> Hi, This implements the logical memory view for Task.getMemory(). It is now possible to view the process memory as if frysk-core hadn't touched it at all. Users can now choose whether to get the raw view (with all the bits in it that frysk-core might have changed for private house keeping) through getRawMemory() or the logical view (which is the default old getMemory() that almost everything outside frysk-core now uses). The gui and fhpd could give the user the option to also get a raw memory view, but in general the user is probably interested in the logical view as the (running) process should see it. fcore could also choose to either dump the logical memory view (which it already does since it just reads the section maps from disk) or include the raw view (but that doesn't seem wise since the user wouldn't know why the "garbage" breakpoint instructions that frysk-core inserted are there). frysk-core/frysk/proc/ChangeLog 2007-07-20 Mark Wielaard * Breakpoint.java: Implements Comparable. (getInstruction): New method. (getProc): New method. (compareTo): New method. * BreakpointAddresses.java (breakpoints): New field. (BreakpointAddresses): Initialize breakpoints. (getBreakpoint): New method. (getBreakpoints): New method. * MemoryMap.java: Make immutable. * Task.java (getRawMemory): New method. * TestTaskObserverCode (testViewBreakpointMemory): New test. (testViewBreakpointMap): New test. (getFunctionDie): New method. (getFunctionEntryAddress): Use getFunctionDie. frysk-core/frysk/proc/live/ChangeLog 2007-07-20 Mark Wielaard * AddressSpaceByteBuffer.java (addressSpace): Now protected. (pid): Likewise. (AddressSpaceByteBuffer): Likewise. * LinuxTask.java (getRawMemory): New method name for sendrecMemory. (sendrecMemory): Implement through LogicalMemoryBuffer. * LogicalMemoryBuffer.java: New class. There are a couple of new tests added for this that now all pass. No regressions on x86_64 Fedora Core 6 and x86 Fedora 7. Although that was somewhat hard to see since there are a couple of always failing and a couple of intermediately failing tests in the tree. It would be nice to get back to zero fail again. A couple of things to note, questions and upcoming work: - Some of the work with our ByteBuffers is somewhat awkward since we pretend everything is longs. But arrays in java cannot address anything bigger than a (positive) int. So having offsets and lengths as longs is somewhat cheating since it will never work in practise. So there is some casting back and forth. Maybe just change the ByteBuffer methods that work on arrays to just take ints for offset and length. - I added some comments about Breakpoints not really being immutable objects which affects the thread-safety of the code. There are some extra checks here and there. But it would be good to go over this. Maybe this isn't really an issue since memory reads should only be done in observers after an event notification. Can observers for different Tasks of the same Proc be signaled simultaneously? - LogicalMemoryBuffer is a filter on top of AddressSpaceByteBuffer but really should be on top of MemorySpaceByteBuffer which is more effecient. The used to be interface compatible, but a recent change to MemorySpaceByteBuffer changed that and made that it less easy to wrap. MemorySpaceByteBuffer is really just an optimization of AddressSpaceByteBuffer (in the case of AddressSpace.TEXT/DATA) and all code should go through the optimized path (StateLessFile) for accessing memory if the AddressSpace allows it. So I am going to merge the two (and fix up the places that currently use the slow path). Then I'll also add the ByteBuffer.get() optimization that Chris pointed out. - It would be nice to have an fhpd examine (gdb's x) command to show the above work to the user (the gui already has a memory view). I like to add that. The hpd spec doesn't seem to have something like this, nor does it seem to have a way for expressions to take the address of functions or raw addresses. Do we already have extensions for that? I haven't yet looked at Nurdin's recent fhpd work, but this might already do most of what I want, and more. So maybe all I need to do is strip stuff from that because I just don't need the more :) Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: logicalmem.patch Type: text/x-patch Size: 25425 bytes Desc: not available URL: From roland@redhat.com Sat Jul 21 00:29:00 2007 From: roland@redhat.com (Roland McGrath) Date: Sat, 21 Jul 2007 00:29:00 -0000 Subject: Dwarf expertise needed In-Reply-To: Sami Wagiaalla's message of Thursday, 19 July 2007 11:30:45 -0400 <469F83A5.8090803@redhat.com> Message-ID: <20070721002912.863E14D05BD@magilla.localdomain> > This is the test case that I am using: > > inline void second(){ > int* a = 0; > a[0] = 0; <-------- pc > } > > void first(){ > second(); > } > > int main(){ > first(); > return 0; > } You need to give me a binary, or at least exact compiler version, arch, and options. A binary is really better, so we can be sure what we are talking about, can refer to precise addresses and DIEs, etc. Thanks, Roland From mark@klomp.org Mon Jul 23 12:19:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 23 Jul 2007 12:19:00 -0000 Subject: Breakpoint stepping In-Reply-To: <468D3A87.4020205@redhat.com> References: <1183573205.3598.157.camel@dijkstra.wildebeest.org> <468D3A87.4020205@redhat.com> Message-ID: <1185193157.3699.13.camel@dijkstra.wildebeest.org> Hi Andrew, On Thu, 2007-07-05 at 14:37 -0400, Andrew Cagney wrote: > Can I suggest adding this, or something based on it, to > frysk.proc.live.package.html? It's this useful! information we should > be accumulating in the source tree. Merged with the old stepping story I send to the list last month and cleanup up to only mention the current implementation details and current deficiencies: 2007-07-23 Mark Wielaard * package.html: New file describing implementation details of Instruction and Code observers. See attached. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: package.html.gz Type: application/x-gzip Size: 3753 bytes Desc: not available URL: From kris.van.hees@oracle.com Mon Jul 23 15:15:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Mon, 23 Jul 2007 15:15:00 -0000 Subject: Automated build-and-test summary reports Message-ID: <20070723151536.GB1451@ca-server1.us.oracle.com> No automated summary reports have been generated for the past 5 days due to every single build-and-test run requiring manual intervention to complete. This has been traced down to hanging tests, although the exact details are still being investigated. One possible cause may be the re-enabling of tests that were marked as unresolved/unsupported in the past. Investigation continues into which exact test is causing the problem. On top of all this, it was found that on FC6 i386, a large mount of TestRunner instances was left hanging after completion of the testsuite. This is also being investigated. I will generate summary reports for the missing days manually and send them out. It didn't happen automaticaly because due to the manual lintervention needed to get test runs unstuck, the results did not get uploaded within the timeframe needed to get picked up by the summary report generation process. If anyone has noticed this behaviour as well, and would have a clue already about what might be going on, please let me know :) It's rather important that we can ensure that tests are guaranteed to complete, one way or another. If a test does not complete in reasonable time, there definitely should be a process in place that aborts it, with appropriate result being logged. Cheers, Kris From cagney@redhat.com Mon Jul 23 16:57:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 23 Jul 2007 16:57:00 -0000 Subject: which elf symbol? Message-ID: <46A4DE19.4000200@redhat.com> Hi, I've replaced the frysk-stackframe program with an expanded frysk-symbols program that has more elf symbol lookup edge cases; for instance nested symbols. I've also expanded frysk.rt.TestSymbol to exercise them. For some of the cases though, the results are not what I expected. I've noted the failures below and provided a simplified assembler. 1) testGlobalAfterNested(frysk.rt.TestSymbol)junit.framework.ComparisonFailure: symbol global_outer expected: but was: at frysk.rt.TestSymbol.symbolTest(TestRunner) at frysk.rt.TestSymbol.testGlobalAfterNested(TestRunner) at frysk.junit.Runner.runCases(TestRunner) at frysk.junit.Runner.runArchCases(TestRunner) at frysk.junit.Runner.runTestCases(TestRunner) at TestRunner.main(TestRunner) 2) testLocalAfterNested(frysk.rt.TestSymbol)junit.framework.ComparisonFailure: symbol local_outer expected:<...outer> but was:<...st_size_0> at frysk.rt.TestSymbol.symbolTest(TestRunner) at frysk.rt.TestSymbol.testLocalAfterNested(TestRunner) at frysk.junit.Runner.runCases(TestRunner) at frysk.junit.Runner.runArchCases(TestRunner) at frysk.junit.Runner.runTestCases(TestRunner) at TestRunner.main(TestRunner) These two are effectively the same. The layout is: local_st_size_0: // this symbol has no size global_outer: nop local_in_global: nop .size local_in_global, .-local_in_global nop <> .size global_outer, .-global_outer that is global_outer contains a nested symbol but the "pc" is beyond that back in the outer/global symbol. I'm guessing that "global_outer" should be returned. Currently local_st_size_0 is returned :-( 3) testNoSymbolAfterGlobal(frysk.rt.TestSymbol)junit.framework.ComparisonFailure: symbol [unknown] expected:<[unknown]> but was: at frysk.rt.TestSymbol.symbolTest(TestRunner) at frysk.rt.TestSymbol.testNoSymbolAfterGlobal(TestRunner) at frysk.junit.Runner.runCases(TestRunner) at frysk.junit.Runner.runArchCases(TestRunner) at frysk.junit.Runner.runTestCases(TestRunner) at TestRunner.main(TestRunner) 4) testNoSymbolAfterLocal(frysk.rt.TestSymbol)junit.framework.ComparisonFailure: symbol [unknown] expected:<[unknown]> but was: at frysk.rt.TestSymbol.symbolTest(TestRunner) at frysk.rt.TestSymbol.testNoSymbolAfterLocal(TestRunner) at frysk.junit.Runner.runCases(TestRunner) at frysk.junit.Runner.runArchCases(TestRunner) at frysk.junit.Runner.runTestCases(TestRunner) at TestRunner.main(TestRunner) This is the no-symbol case, there is a hole in the memory where there is no valid symbol vis: local_st_size_0: // this symbol has no size global_symbol: nop nop .size global_symbol, .-global_symbol << you are here >> I'm guessing it should not get a symbol at all (the [unknown]). It currently gets the nearest unsized symbol. 5) testGlobalSize0InGlobal(frysk.rt.TestSymbol)junit.framework.ComparisonFailure: symbol global_0_in_global expected:<...0_in_global> but was:<...after_0> at frysk.rt.TestSymbol.symbolTest(TestRunner) at frysk.rt.TestSymbol.testGlobalSize0InGlobal(TestRunner) at frysk.junit.Runner.runCases(TestRunner) at frysk.junit.Runner.runArchCases(TestRunner) at frysk.junit.Runner.runTestCases(TestRunner) at TestRunner.main(TestRunner) 6) testLocalSize0InGlobal(frysk.rt.TestSymbol)junit.framework.ComparisonFailure: symbol local_0_in_global expected: but was: at frysk.rt.TestSymbol.symbolTest(TestRunner) at frysk.rt.TestSymbol.testLocalSize0InGlobal(TestRunner) at frysk.junit.Runner.runCases(TestRunner) at frysk.junit.Runner.runArchCases(TestRunner) at frysk.junit.Runner.runTestCases(TestRunner) at TestRunner.main(TestRunner) 7) testGlobalSize0InLocal(frysk.rt.TestSymbol)junit.framework.ComparisonFailure: symbol global_0_in_local expected: but was: at frysk.rt.TestSymbol.symbolTest(TestRunner) at frysk.rt.TestSymbol.testGlobalSize0InLocal(TestRunner) at frysk.junit.Runner.runCases(TestRunner) at frysk.junit.Runner.runArchCases(TestRunner) at frysk.junit.Runner.runTestCases(TestRunner) at TestRunner.main(TestRunner) 8) testLocalSize0InLocal(frysk.rt.TestSymbol)junit.framework.ComparisonFailure: symbol local_0_in_local expected:<...0_in_local> but was:<...after_0> at frysk.rt.TestSymbol.symbolTest(TestRunner) at frysk.rt.TestSymbol.testLocalSize0InLocal(TestRunner) at frysk.junit.Runner.runCases(TestRunner) at frysk.junit.Runner.runArchCases(TestRunner) at frysk.junit.Runner.runTestCases(TestRunner) at TestRunner.main(TestRunner) These are cases where there is a nested symbol within a sized symbol vis: global_after_0: nop local_0_in_global: << you are here >> nop .size global_after_0, .-global_after_0 here, since the PC is exactly at the unsized local symbol I'm guessing that it should return that. It currently gets the containing sized symbol. From pmuldoon@redhat.com Tue Jul 24 23:48:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 24 Jul 2007 23:48:00 -0000 Subject: frysk-cvs patch tuning In-Reply-To: <469D0DE7.5020409@redhat.com> References: <469CE638.60900@redhat.com> <469D0DE7.5020409@redhat.com> Message-ID: <46A68FD4.9010308@redhat.com> Andrew Cagney wrote: > > > Phil Muldoon wrote: >> Is it possible to tune frysk-cvs mailing list to include patches, and >> not links to patches? I find this list very useful, and read the >> list/patches everyday. but I hate the mass clicking on links. It >> would make reply-to questions on some code more context-friendly if >> the patch part is included in the email. >> > Well, if we switched from CVS then this would be a non-issue. I > wonder if that is a better solution. (Would certainly have made my > life this morning easier :-) I've been playing with Mercurial lately, and I did an import of the Frysk CVS head using Tailor. I was not able to import any branches or any change-set information which was disappointing. That might be a lack of information on my part. Or the wrong conversion tool. Others might have more luck. But from an experimental viewpoint, I really, really did like the concept of Mercurial and distributed version control. There are other similar systems (GIT comes to mind). I really like the idea of having your own control of your own local repository, pull and pushing change-sets from a "main" repository, and so on. And it would help tremendously in branches (not to mention diffs, patch review and so on). I don't have an outward facing machine so this is all locally done on my machine. But it after taking a walk away from CVS, I'm not keen to go back ;) Regards Phil From cagney@redhat.com Wed Jul 25 01:43:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 25 Jul 2007 01:43:00 -0000 Subject: frysk-core movements frysk.testbed.TestLib and frysk.hpd Message-ID: <46A6AAE1.3010700@redhat.com> FYI, -> I finally took another of steps towards breaking frysk.proc.TestLib down into a number of frysk.testbed.* classes. This one was to move that class to frysk.testbed.TestLib. Will make breaking it down further much easier. -> similarly, I've removed the redundant frysk.cli package, with the hpd now in frysk.hpd. Following suit, most of the frysk.bindir.TestFhd tests have been moved to frysk.hpd. For the moment they still run "fhpd" but going forward it should be possible to have these tests run the HPD as a separate thread within TestRunner (will greatly speed up the test run). Andrew From mark@klomp.org Wed Jul 25 11:30:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 25 Jul 2007 11:30:00 -0000 Subject: [patch] Stat vs slurp vs linux 2.6.22 Message-ID: <1185363024.3597.16.camel@dijkstra.wildebeest.org> Hi, On newer kernels (2.6.22) not just init (process id 1) can have a zero parent pid, but other kernel processes/threads also have a parent pid of zero (in particular kthreadd). This was done for systems with thousands of CPUs which create ten-thousand (kernel) processes and having them all children of init was not scaling (and not really necessary for the kernel-threads, which don't need to be reaped by init in the first place). This exposed a bug in our Stat parsing through LinuxHost. See http://sourceware.org/bugzilla/show_bug.cgi?id=4838 Stat uses slurp which was written to handle these kind of issues where /proc//stat might not exist or disappear in between calls. But it relied on the slurp() functions returning a failure value (NULL or -1). A recent rewrite of slurp to use Errno.tryOpen() which throws an Exception on error, broke Stat handling in such cases. Besides that slurp() had a bug in that it could free() a given buffer that it hadn't created itself (Stat was the owner of that buffer), this could lead to strange memory corruption. Both issues were fixed by: 2007-07-25 Mark Wielaard Fixes bug #4838 * cni/slurp.cxx (uslurp): Catch Errno after tryOpen(). (slurp): Likewise and don't free given buffer and return -1. (slurp_thread): Likewise. Tested on x86_64 (Fedora Core 6) and x86 (Fedora 7 - with new 2.6.22 kernel). The failing tests reported in the bug report PASS with this test on the new kernel. And introduces no new FAILs. It might make sense to rewrite slurp as a normal java class so these cross C/Java error handling issues. Is there a reason for slurp to have to be written in C/CNI? Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: slurp.patch Type: text/x-patch Size: 1919 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Wed Jul 25 11:53:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 25 Jul 2007 11:53:00 -0000 Subject: frysk-sys/frysk bindir/ChangeLog proc/live/Cha ... In-Reply-To: <20070718191111.26695.qmail@sourceware.org> References: <20070718191111.26695.qmail@sourceware.org> Message-ID: <1185364424.3597.18.camel@dijkstra.wildebeest.org> Hi Andrew, On Wed, 2007-07-18 at 19:11 +0000, cagney@sourceware.org wrote: > 2007-07-18 Andrew Cagney > > * LinuxProc.java: Use frysk.sys.proc.Exe.get. Validate the > returned string, returning NULL when a problem. > /** > * A Linux Proc tracked using PTRACE. > @@ -199,19 +199,32 @@ > } > /** > * Get the Executable. > - */ > - protected String sendrecExe () > - { > - String exeString = "/proc/" + getPid() + "/exe"; > - try > - { > - exeString = new File(exeString).getCanonicalPath(); > - } > - catch (IOException ioe) > - { > - // Just return exeString. No permission or process died. > - } > - return exeString; > + * > + * XXX: This is racy - it can miss file renames. The alternative > + * would be to have two methods; one returning a file descriptor > + * and a second returning the exe as it should be (but possibly > + * isn't :-). Better yet have utrace handle it :-) > + */ > + protected String sendrecExe () { > + String exe = Exe.get(getPid()); > + // Linux's /proc/$$/exe can get screwed up in several ways. > + // Detect each here and return null. > + if (exe.endsWith(" (deleted)")) > + // Assume (possibly incorrectly) that a trailing > + // "(deleted)" always indicates a deleted file. > + return null; > + if (exe.indexOf((char)0) >= 0) > + // Assume that an EXE that has somehow ended up with an > + // embedded NUL character is invalid. This happens when > + // the kernel screws up "mv a-really-long-file $exe" > + // leaving the updated EXE string with something like > + // "$exeally-long-file (deleted)". > + return null; > + if (new File(exe).exists()) > + // Final sanity check; the above two should have covered > + // all possible cases. But one never knows. > + return exe; > + return null; > } This break FryskGui which isn't prepared to handle null from Proc.get(). It is probably a good idea to make Proc.get() return a File object that the user can then inspect themselves (you won't get rid of the race anyway unless you explicitly open the file and return that as result, but that is probably not what you want here), then you can also easily find all users of this method so you can inspect whether or not they handle the new return value correctly. 2007-07-18 Andrew Cagney * cni/Exe.cxx (get): Allow space for "(deleted)"). If you do make getExe() return File, then you can also just use the standard File.getCanonicalFile() method, which will do all sanity checking already in proc.Exe so we don't need a special case cni implementation for it and doesn't depend on fixed buffer lengths. Cheers, Mark From mark@klomp.org Wed Jul 25 12:07:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 25 Jul 2007 12:07:00 -0000 Subject: [patch] PickProcDialog vs Proc.getExe() In-Reply-To: <1185364424.3597.18.camel@dijkstra.wildebeest.org> References: <20070718191111.26695.qmail@sourceware.org> <1185364424.3597.18.camel@dijkstra.wildebeest.org> Message-ID: <1185365221.3597.25.camel@dijkstra.wildebeest.org> Hi, On Wed, 2007-07-25 at 13:53 +0200, Mark Wielaard wrote: > This break FryskGui which isn't prepared to handle null from Proc.get(). Here is a workaround for at least one case (there might be others, but I haven't looked too deeply yet). This gets FryskGui up and running again for me. 2007-07-25 Mark Wielaard * PickProcDialog.java (ProcCreatedObserver.run): Check whether Proc.getExe() returns null before constructing File path. Cheers, Mark diff -u -r1.12 PickProcDialog.java --- frysk-gui/frysk/gui/monitor/PickProcDialog.java 30 Jan 2007 00:18:21 -0000 1.12 +++ frysk-gui/frysk/gui/monitor/PickProcDialog.java 25 Jul 2007 11:55:53 -0000 @@ -355,11 +355,14 @@ { iterMap.put(proc.getCommand(), process); treeStore.setValue(process, nameDC, proc.getCommand()); - File path = new File(proc.getExe()); - - if (path != null) - treeStore.setValue(process, locationDC, - justPath(path.getPath(), path.getName())); + + String exe = proc.getExe(); + if (exe != null) + { + File path = new File(exe); + treeStore.setValue(process, locationDC, + justPath(path.getPath(), path.getName())); + } else treeStore.setValue(process, locationDC, ""); From cagney@redhat.com Wed Jul 25 13:27:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 25 Jul 2007 13:27:00 -0000 Subject: meeting 2007-07-25 9:30 US east coast time Message-ID: <46A74FCB.1050302@redhat.com> (all welcome, contact me off list for north american toll free number) This week: Nurdin will demo the disassembler command; and perhaps fstack. See IRC for how to get access to thedemo server. From cagney@redhat.com Wed Jul 25 13:27:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 25 Jul 2007 13:27:00 -0000 Subject: frysk ui meeting 2007-07-18 9:30 US east coast time In-Reply-To: <469D089A.5050002@redhat.com> References: <469D089A.5050002@redhat.com> Message-ID: <46A74FD8.6060803@redhat.com> Display: [mark posted the log from the terminal window] Bugs found; none were display related! bug#1 break command syntax (existing bug) Should be <> and not <> bug#2 In list command, where am i? Vis: (fhpd) list 10 asdf 11 bdf 12 ggh 13 uuh (fhpd) which line; (pick this one up this week with the disassembler) bug#3 mixed output [mcvet] (fhpd) go Breakpoint at 10 hit where is the prompt to indicate that the user has control again and there isn't any more output bug#4 4747 Panic some times when stepping. bug#5 Tie the displayed PID to the session's task/proc ID [timoore] ---- Ideas: for display -- extend to include dynamic display; for instance: display $pc -format iinstruction bug#6 deleted breakpoints not deleted Apparently they only get disabled. bug#7 no notification when task exits --- Idea's for location syntax: -> can it be extended to include column number vis #LINE#COL -> way to specify an address ---- Round table: Mark: -> writing up documentation on ptrace/stepper -> finishing instruction parser framework -> memory bug 4761 -> memory access optimization 4760 -> follow up with 4747 Adam: -> demo of display -> will be tieing up loos ends Tim: -> working on HPD's proc/task syntax (dusting off the cobwebs) Mike: -> Looking at parser and source window bugs -> chasing breakpoint bugs in stepper Nurdin: -> implemented better dwfl cache; refreshes instead of re-opens dwfl after stop -> disassembler in fhpd Teresa: -> utility to display required debug info -> has script listing debug info to install working Sami: -> Fixing problems with displaying variables -> Finished printing variables on stack -> back to chasing problems with getting correct scope information from dwfl Cagney: -> ongoing cleanups -> looking for dwfl memory leeks Kris: -> looking at documentation -> looking to modify test system to recover from kernel crashes (more robust) -> working through memory window bugs Phil: -> makin corefile stuff more robust and rounding it out Rick: -> More source window issues with existing parser; bash is especially nasty. --- Next week: disassembler, fstack? fdebuginfo? Andrew Cagney wrote: > (contact me for dial in info, in North America it's a free call) > > This week we're going to look at the "display" stuff adam has been > working on. In particular, what it is and how it can be used :-) > > All welcome. > > Andrew > From cagney@redhat.com Wed Jul 25 13:30:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 25 Jul 2007 13:30:00 -0000 Subject: [patch] Stat vs slurp vs linux 2.6.22 In-Reply-To: <1185363024.3597.16.camel@dijkstra.wildebeest.org> References: <1185363024.3597.16.camel@dijkstra.wildebeest.org> Message-ID: <46A75077.2020706@redhat.com> Mark Wielaard wrote: > Hi, > > On newer kernels (2.6.22) not just init (process id 1) can have a zero > parent pid, but other kernel processes/threads also have a parent pid of > zero (in particular kthreadd). This was done for systems with thousands > of CPUs which create ten-thousand (kernel) processes and having them all > children of init was not scaling (and not really necessary for the > kernel-threads, which don't need to be reaped by init in the first > place). This exposed a bug in our Stat parsing through LinuxHost. See > http://sourceware.org/bugzilla/show_bug.cgi?id=4838 > > Stat uses slurp which was written to handle these kind of issues > where /proc//stat might not exist or disappear in between calls. > But it relied on the slurp() functions returning a failure value (NULL > or -1). A recent rewrite of slurp to use Errno.tryOpen() which throws an > Exception on error, broke Stat handling in such cases. Besides that > slurp() had a bug in that it could free() a given buffer that it hadn't > created itself (Stat was the owner of that buffer), this could lead to > strange memory corruption. Both issues were fixed by: > > > 2007-07-25 Mark Wielaard > > Fixes bug #4838 > * cni/slurp.cxx (uslurp): Catch Errno after tryOpen(). > (slurp): Likewise and don't free given buffer and return -1. > (slurp_thread): Likewise. > > Tested on x86_64 (Fedora Core 6) and x86 (Fedora 7 - with new 2.6.22 > kernel). The failing tests reported in the bug report PASS with this > test on the new kernel. And introduces no new FAILs. > > It might make sense to rewrite slurp as a normal java class so these > cross C/Java error handling issues. Is there a reason for slurp to have > to be written in C/CNI? > -> memory pressure; notice how it does a callback -> performance it was written in java > Cheers, > > Mark > > ------------------------------------------------------------------------ > > Index: frysk-sys/frysk/sys/proc/cni/slurp.cxx > =================================================================== > RCS file: /cvs/frysk/frysk-sys/frysk/sys/proc/cni/slurp.cxx,v > retrieving revision 1.10 > diff -u -r1.10 slurp.cxx > --- frysk-sys/frysk/sys/proc/cni/slurp.cxx 18 Jul 2007 18:23:52 -0000 1.10 > +++ frysk-sys/frysk/sys/proc/cni/slurp.cxx 25 Jul 2007 10:53:47 -0000 > @@ -1,6 +1,6 @@ > // This file is part of the program FRYSK. > // > -// Copyright 2005, Red Hat Inc. > +// Copyright 2005, 2007 Red Hat Inc. > // > // FRYSK is free software; you can redistribute it and/or modify it > // under the terms of the GNU General Public License as published by > @@ -47,6 +47,7 @@ > > #include > > +#include "frysk/sys/Errno.h" > #include "frysk/sys/cni/Errno.hxx" > #include "frysk/sys/proc/cni/slurp.hxx" > > @@ -73,7 +74,15 @@ > } > > // Open the file file. > - int fd = tryOpen (file, O_RDONLY, 0); > + int fd; > + try > + { > + fd = tryOpen (file, O_RDONLY, 0); > + } > + catch (frysk::sys::Errno *ignored) > + { > + fd = 0; > + } > if (!fd) > { > ::free (buf); > @@ -127,12 +136,18 @@ > throwRuntimeException ("snprintf: buffer overflow"); > > // Open the file file. > - int fd = tryOpen (file, O_RDONLY, 0); > - > + int fd; > + try > + { > + fd = tryOpen (file, O_RDONLY, 0); > + } > + catch (frysk::sys::Errno *ignored) > + { > + fd = 0; > + } > if (!fd) > { > - ::free (buf); > - return 0; > + return -1; > } > > > @@ -165,12 +180,18 @@ > throwRuntimeException ("snprintf: buffer overflow"); > > // Open the file file. > - int fd = tryOpen (file, O_RDONLY, 0); > - > + int fd; > + try > + { > + fd = tryOpen (file, O_RDONLY, 0); > + } > + catch (frysk::sys::Errno *ignored) > + { > + fd = 0; > + } > if (!fd) > { > - ::free (buf); > - return 0; > + return -1; > } > > > From mark@klomp.org Wed Jul 25 14:59:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 25 Jul 2007 14:59:00 -0000 Subject: [patch] Stat vs slurp vs linux 2.6.22 In-Reply-To: <46A75077.2020706@redhat.com> References: <1185363024.3597.16.camel@dijkstra.wildebeest.org> <46A75077.2020706@redhat.com> Message-ID: <1185375592.3597.40.camel@dijkstra.wildebeest.org> Hi Andrew, On Wed, 2007-07-25 at 09:30 -0400, Andrew Cagney wrote: > > It might make sense to rewrite slurp as a normal java class so these > > cross C/Java error handling issues. Is there a reason for slurp to have > > to be written in C/CNI? > > > -> memory pressure; notice how it does a callback > -> performance Interesting. It does feel a little like a premature optimization though, seeing that we are finding bugs in it because of the Java/C/CNI mixture of error and memory handling that are hard to track down. How precisely do callbacks work in slurp (I have to admit that I haven't noticed them) and why can't you do that with a normal java implementation? Thanks, Mark From elena.zannoni@oracle.com Wed Jul 25 15:25:00 2007 From: elena.zannoni@oracle.com (Elena Zannoni) Date: Wed, 25 Jul 2007 15:25:00 -0000 Subject: Meeting minutes 2007-07-25 Message-ID: <46A76B91.60702@oracle.com> Apologies for not sending minutes last week, I didn't have a chance to attend the meeting. Here are the minutes for today's meeting. elena -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: frysk-20070725 URL: From cagney@redhat.com Wed Jul 25 15:27:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 25 Jul 2007 15:27:00 -0000 Subject: meeting 2007-07-25 9:30 US east coast time In-Reply-To: <46A74FCB.1050302@redhat.com> References: <46A74FCB.1050302@redhat.com> Message-ID: <46A76C18.5020102@redhat.com> [toronto hit a technical hurdle with a machine, round table was first] cagney: -> moved fhpd to frysk.hpd and created per-command tests in that directory; for instance frysk.hpd.TestStackCommands everyone encouraged to continue -> overhauled frysk-asm.h; with mike got it working with CFI so that assembler can produce correct stack backtraces teresa: -> continuing with debug-info installing -> got fdebuginfo working -> lists debug info files for program -> next utility [fdebugrpm] will install missing debuginfo using yum/sudo -> extension is to install debuginfo locally (i.e., not as super-user) stan; [away] -> overhauled expression parser to -> fixed breakpoint syntax to use "#" instead of "@", ya!!! rick: -> fighting source window vs bash; added recovery code so that when things go wrong an un-marked source window will be displayed (which is way way better than a stack backtrace) -> investigating slowdown when examining bash sources phil: -> hopefully closing out corefile cleanups: corefile factory; streaming data to file (instead of double buffering) as final speed up -> discussion about where to put the refactored code. For momment frysk.util, but frysk.corefile might be final resting place suggestion of the addition of a dump core button/command kris: -> documenting stepping engine (the one in frysk.rt) -> chasing another fd0 closed bug -> working on crash recovery in automated builds -> helping pearl come up-to-speed with memory and disassembler changes pearl: -> Working on memory and disassembler windows/bugs [cagney asked if pearl could assign her self these bugs] mark: -> finishing logical-memory (memory where breakpoints are not visible) object -> have reproducer for 4747; need to handle a signal becomming pending during a step (part of finishing up stepping; "fix" is to break it down into two events - one notifying that a signal is pending (then unblocked) and one notifying that a step to first instruction of signal handler has occured. -> studying libunwind, dwarf doco, and looking at rpm notes sami: -> testing new fstack [will commit to branch] -> working to get libdwfl to return needed scope information -> changed stack code to use print writer ---- // ---- Demo one: fstack -a <> -> displays all known variables and their status bug#0 likely two many variable optimized out messages(investigating) bug#1 when printing a string, can it be "C"ified; for instance char *foo = "abc\r\n" bug#2 include solib in default (or elf) backtrace (it was added to the -a output which is much better) bug#3 add # as prefix to file name so that it can be cut/paste to breakpoint code [side discussion about that, example of foo.c#23 not being clearly a file or a struct] bug#4 add way to specify other scopes bug#5 print available line number information for each variable ---- // ---- Demo two: disassemble command <> -> displays assembler _round_ the pc and not assembler of entire function -> has marker showing were $pc or address is bug#0 option to disassemble entire function bug#1 disassembler for non-native architecture (DisassemblerFactory) bug#2 core file didn't work :-( bug#4 < >> didn't disassemble correct address bug#5 fhpd usage message out-of-date bug#6 list command's "*" marker should be before line number (so it isn't confused with source code) bug#7 list commands "*" isn't in the middle of the listed code ---- // ---- different brekpoint addresses: case #1: function prologue A "traditional" function looks something like: entry_point: <---- break *entry_point set-up new stack frame [prologue] <---- break entry_point .... code proper ... tear down stack frame [epilogue] return (for details see frysk-asm.h's macros). When setting a breakpoint it can either be set before after the prologue code. DWARF provides information that specifies where the end of the prologue is and so when stepping into or halting at a function it can stop after the frame is constructed instead of before. The difference is marginal, and with modern ISAs there typically isn't a proper frame anyway. case#2 c++ constructors Consider something like: class parent { parent() ... } class child extends parent { child () ... } In C++, parent, for constructor parent() has two methods; one is called for the case of "new parent()" and a second is called for the case of "new child()". case#3 none of the above; to discuss on IRC ./ From cagney@redhat.com Wed Jul 25 15:39:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 25 Jul 2007 15:39:00 -0000 Subject: [patch] Stat vs slurp vs linux 2.6.22 In-Reply-To: <1185375592.3597.40.camel@dijkstra.wildebeest.org> References: <1185363024.3597.16.camel@dijkstra.wildebeest.org> <46A75077.2020706@redhat.com> <1185375592.3597.40.camel@dijkstra.wildebeest.org> Message-ID: <46A76EDB.1080400@redhat.com> Mark Wielaard wrote: > Hi Andrew, > > On Wed, 2007-07-25 at 09:30 -0400, Andrew Cagney wrote: > >>> It might make sense to rewrite slurp as a normal java class so these >>> cross C/Java error handling issues. Is there a reason for slurp to have >>> to be written in C/CNI? >>> >>> >> -> memory pressure; notice how it does a callback >> -> performance >> > > Interesting. It does feel a little like a premature optimization though, > seeing that we are finding bugs in it because of the Java/C/CNI mixture > of error and memory handling that are hard to track down. > > We're talking here about Scan, not slurp; the first implementation did use File et.al. It was changed from java to a builder to reduce memory pressure and produced a dramatic performance boost. Scan, by not double allocating memory read also keeps memory pressure down. Going forward, the less memory dropped on the floor by the core, the easier it will be to push more of this into C++. Andrew > > From cagney@redhat.com Wed Jul 25 16:24:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 25 Jul 2007 16:24:00 -0000 Subject: new command fexe In-Reply-To: <1184834265.3629.21.camel@dijkstra.wildebeest.org> References: <469E678F.1020101@redhat.com> <1184834265.3629.21.camel@dijkstra.wildebeest.org> Message-ID: <46A7793B.1070207@redhat.com> Mark, something like this: cagney@nettle$ cp /bin/bash /tmp cagney@nettle$ /tmp/bash cagney@nettle$ cp /bin/bash /tmp/a-very-long-file cagney@nettle$ mv !$ /tmp/bash mv /tmp/a-very-long-file /tmp/bash cagney@nettle$ /home/scratch/frysk/native/frysk-core/frysk/bindir/fexe $$ null cagney@nettle$ /home/scratch/frysk/native/frysk-core/frysk/bindir/fexe -v $$ 3905 null /tmp/bash4]setspeed (deleted) cagney@nettle$ ? Mark Wielaard wrote: > Hi Andrew, > > On Wed, 2007-07-18 at 15:18 -0400, Andrew Cagney wrote: > >> This is from the man page: >> >> $ cp /bin/bash /tmp/sh >> $ PS1=???sh$ ??? /tmp/sh >> sh$ fexe $$ >> /tmp/sh >> sh$ rm /tmp/sh >> sh$ fexe -v $$ >> 1234 null /tmp/sh (deleted) >> > > Can you use this to show that soft link bug a softlink contains a \0 > character in it? It would be good to have a showcase of that so we can > report it upstream. > > Cheers, > > Mark > From roland@redhat.com Thu Jul 26 02:27:00 2007 From: roland@redhat.com (Roland McGrath) Date: Thu, 26 Jul 2007 02:27:00 -0000 Subject: which elf symbol? In-Reply-To: Andrew Cagney's message of Monday, 23 July 2007 12:58:01 -0400 <46A4DE19.4000200@redhat.com> Message-ID: <20070726022738.4350E4D058D@magilla.localdomain> I reduced your report to an isolated test case of trivial assembly. I've slightly modified addr2line so I'm using it as a test program with -e on the .o file to just print out the results of dwfl_module_addrsym. Please help me adjust this test case to match (or also include) cases equivalent to what you are seeing. .globl t1_global_outer t1_local_st_size_0: t1_global_outer: nop t1_local_in_global: nop .size t1_local_in_global, .-t1_local_in_global 1: nop .size t1_global_outer, .-t1_global_outer .space 100 .balign 8 .globl t2_global_symbol t2_local_st_size_0: t2_global_symbol: nop nop .size t2_global_symbol, .-t2_global_symbol 2: .space 100 .balign 8 .globl t3_global_after_0 t3_global_after_0: nop t3_local_0_in_global: 3: nop .size t3_global_after_0, .-t3_global_after_0 .data t1_pc_of_interest: .long 1b t2_pc_of_interest: .long 2b t3_pc_of_interest: .long 3b as on that produces the following (readelf -rs; objdump -d). The reloc addends tell you the "pc_of_interest" values. On i386 (non-rela), you'd need to look at objdump -s -j .data instead to see them. Relocation section '.rela.data' at offset 0x560 contains 3 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000000000 00010000000a R_X86_64_32 0000000000000000 .text + 2 000000000004 00010000000a R_X86_64_32 0000000000000000 .text + 6a 000000000008 00010000000a R_X86_64_32 0000000000000000 .text + d1 Symbol table '.symtab' contains 14 entries: Num: Value Size Type Bind Vis Ndx Name 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 1: 0000000000000000 0 SECTION LOCAL DEFAULT 1 2: 0000000000000000 0 SECTION LOCAL DEFAULT 2 3: 0000000000000000 0 SECTION LOCAL DEFAULT 4 4: 0000000000000000 0 NOTYPE LOCAL DEFAULT 1 t1_local_st_size_0 5: 0000000000000001 1 NOTYPE LOCAL DEFAULT 1 t1_local_in_global 6: 0000000000000068 0 NOTYPE LOCAL DEFAULT 1 t2_local_st_size_0 7: 00000000000000d1 0 NOTYPE LOCAL DEFAULT 1 t3_local_0_in_global 8: 0000000000000000 0 NOTYPE LOCAL DEFAULT 2 t1_pc_of_interest 9: 0000000000000004 0 NOTYPE LOCAL DEFAULT 2 t2_pc_of_interest 10: 0000000000000008 0 NOTYPE LOCAL DEFAULT 2 t3_pc_of_interest 11: 0000000000000000 3 NOTYPE GLOBAL DEFAULT 1 t1_global_outer 12: 0000000000000068 2 NOTYPE GLOBAL DEFAULT 1 t2_global_symbol 13: 00000000000000d0 2 NOTYPE GLOBAL DEFAULT 1 t3_global_after_0 addrsym-test.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 : 0: 90 nop 0000000000000001 : 1: 90 nop 2: 90 nop ... 67: 90 nop 0000000000000068 : 68: 90 nop 69: 90 nop ... ce: 66 90 xchg %ax,%ax 00000000000000d0 : d0: 90 nop 00000000000000d1 : d1: 90 nop It's possible the order of symbols in the table is an issue. So let me know if those are different in your case. > local_st_size_0: // this symbol has no size > > global_outer: > nop > local_in_global: > nop > .size local_in_global, .-local_in_global > nop > <> > .size global_outer, .-global_outer > > that is global_outer contains a nested symbol but the "pc" is beyond > that back in the outer/global symbol. > > I'm guessing that "global_outer" should be returned. Currently > local_st_size_0 is returned :-( Arguably the answer should be no symbol, since the address is past the end of the nearest symbol's size. This is t1 in my test case, looking at pc=0x2. I get t1_global_outer+0x2 from addrsym here, so my case must differ from what you tried here. Can you figure out how they differ? > This is the no-symbol case, there is a hole in the memory where there is > no valid symbol vis: > > local_st_size_0: // this symbol has no size > > global_symbol: > nop > nop > .size global_symbol, .-global_symbol > > << you are here >> > > I'm guessing it should not get a symbol at all (the [unknown]). It > currently gets the nearest unsized symbol. This is t2 in my test case, looking at pc=0x6a. I get t2_local_st_size_0+0x2 here. Go figure. You wrote your marker in a different place, but there is no address difference between the context before the .size directive in the assembly source and the context after it. So unless I'm misunderstanding what cases you intended to describe, this should be the same case as t1. (It doesn't really matter that there is a local symbol nearby, since the PC of interest is unambiguous outside that symbol's address range.) I'll look into why they come out differently, which might relate to some other symptom. I also agree that the right answer is no symbol. > These are cases where there is a nested symbol within a sized symbol vis: > > global_after_0: > nop > local_0_in_global: > << you are here >> > nop > .size global_after_0, .-global_after_0 > > here, since the PC is exactly at the unsized local symbol I'm guessing > that it should return that. It currently gets the containing sized symbol. This is my t3. I get t3_global_after_0+0x1 as you say. This is the intended behavior, not a bug. We can discuss what the behavior should be. /* Handwritten assembly symbols sometimes have no st_size. If no symbol with proper size includes the address, we'll use the closest one that is in the same section as ADDR. */ Usually size-0 symbols are local assembler labels, and sized symbols are the entry points. For things like backtraces, people usually want to see the symbol names for the entry points (plus offsets) rather than the local labels that often have unhelpful names. That's what I had in mind when I wrote that. addrsym started out as addrname, which does not pass back an offset and only used for "what function is this in?" kinds of queries. For that, it clearly makes more sense to prefer the containing sized symbol. However, for things like disassembly, people probably would like to see the local label names, or perhaps both names. Thanks, Roland From kris.van.hees@oracle.com Thu Jul 26 03:49:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Thu, 26 Jul 2007 03:49:00 -0000 Subject: Broken build Message-ID: <20070726034913.GB20459@ca-server1.us.oracle.com> The following checkin broke the build (as verified by both the automated build process and manual verification). I'd recommend not doing a cvs update until this is resolved. 2007-07-25 Andrew Cagney * StressAttachDetachRapidlyForkingMainTask.java: Update; frysk.testbed.TestLib.AttachedDaemonProcess moved to frysk.testbed.DaemonBlockedAtEntry. * TestMemory.java: Ditto. * TestProcGet.java: Ditto. * TestTaskForkedObserver.java: Ditto. * TestTaskSyscallObserver.java: Ditto. * TestTaskObserverBlocked.java: Ditto. * TestRegisters.java: Ditto. * TestTaskClonedObserver.java: Ditto. * TestTaskTerminateObserver.java: Ditto. * StressAttachDetachManyTasks.java: Update; TaskObserverBase * moved from frysk.testbed.TestLib to frysk.testbed.TaskObserverBase. * StressAttachDetachRapidlyCloningMainTask.java: Ditto. * StressAttachDetachRapidlyForkingMainTask.java: Ditto. * StressAttachDetachSignaledTask.java: Ditto. * SyscallExaminer.java: Ditto. * TestMemory.java: Ditto. * TestExec.java: Ditto. * TestIsa.java: Ditto. * TestRegisters.java: Ditto. * TestRun.java: Ditto. * TestTaskClonedObserver.java: Ditto. * TestTaskObserverBlocked.java: Ditto. * TestTaskObserverDetach.java: Ditto. * TestTaskSyscallObserver.java: Ditto. * TestTaskObserver.java: Ditto. * TestTaskForkedObserver.java: Ditto. * TestTaskTerminateObserver.java: Ditto. * TestProcTasksObserver.java: Update; TaskSet moved from frysk.testbed.TestLib to frysk.testbed.TaskSet. * TestRun.java: Ditto. * TestTaskObserverBlocked.java: Ditto. * TestTaskClonedObserver.java: Update; Fibonacci moved from frysk.testbed.TestLib to separate class. * TestTaskObserverBlocked.java: Ditto. * TestTaskForkedObserver.java: Ditto. The reported error is: /home/frysk/build_farm/frysk_incr/frysk_config/frysk-core/frysk/proc/StressAttachDetachRapidlyForkingMainTask.java:47: error: Class or interface 'frysk.testbed.DaemonBlockedAtEntry' not found in import. import frysk.testbed.DaemonBlockedAtEntry; ^ /home/frysk/build_farm/frysk_incr/frysk_config/frysk-core/frysk/proc/StressAttachDetachRapidlyForkingMainTask.java:76: error: Type 'DaemonBlockedAtEntry' not found in the declaration of the local variable 'child'. DaemonBlockedAtEntry child = new DaemonBlockedAtEntry (new String[] ^ 2 errors make[2]: *** [frysk/proc/StressAttachDetachRapidlyForkingMainTask.o] Error 1 From mark@klomp.org Thu Jul 26 06:36:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Thu, 26 Jul 2007 06:36:00 -0000 Subject: Broken build In-Reply-To: <20070726034913.GB20459@ca-server1.us.oracle.com> References: <20070726034913.GB20459@ca-server1.us.oracle.com> Message-ID: <1185431764.3630.7.camel@dijkstra.wildebeest.org> Hi Kris, On Wed, 2007-07-25 at 20:49 -0700, Kris Van Hees wrote: > The following checkin broke the build (as verified by both the automated > build process and manual verification). I'd recommend not doing a cvs > update until this is resolved. Thanks for the warning. > 2007-07-25 Andrew Cagney > > * StressAttachDetachRapidlyForkingMainTask.java: Update; > frysk.testbed.TestLib.AttachedDaemonProcess moved to > frysk.testbed.DaemonBlockedAtEntry. > [...] > The reported error is: > > /home/frysk/build_farm/frysk_incr/frysk_config/frysk-core/frysk/proc/StressAttachDetachRapidlyForkingMainTask.java:47: > error: Class or interface 'frysk.testbed.DaemonBlockedAtEntry' not found > in import. > import frysk.testbed.DaemonBlockedAtEntry; > ^ > /home/frysk/build_farm/frysk_incr/frysk_config/frysk-core/frysk/proc/StressAttachDetachRapidlyForkingMainTask.java:76: > error: Type 'DaemonBlockedAtEntry' not found in the declaration of the > local variable 'child'. > DaemonBlockedAtEntry child = new DaemonBlockedAtEntry (new > String[] > ^ > 2 errors > make[2]: *** [frysk/proc/StressAttachDetachRapidlyForkingMainTask.o] > Error 1 I tried to reconstruct this commit and came up with the following: 2007-07-26 Mark Wielaard * DaemonBlockedAtEntry.java: New file. This seems to do what was intended. It doesn't give a full clean testrun, but the following failures seem to not be caused by this change (I haven't had a full clean testrun for a while now): There were 2 errors: 1) testHpdClass(frysk.hpd.TestPrint)frysk.expunit.TimeoutException: Timeout of 5 expired at frysk.expunit.Expect.expectMilliseconds(TestRunner) at frysk.expunit.Expect.expect(TestRunner) at frysk.expunit.Expect.expect(TestRunner) at frysk.expunit.Expect.expect(TestRunner) at frysk.expunit.Expect.expect(TestRunner) at frysk.hpd.TestPrint.testHpdClass(TestRunner) at frysk.junit.Runner.runCases(TestRunner) at frysk.junit.Runner.runArchCases(TestRunner) at frysk.junit.Runner.runTestCases(TestRunner) at TestRunner.main(TestRunner) 2) testHpdArray(frysk.hpd.TestPrint)frysk.expunit.TimeoutException: Timeout of 5 expired at frysk.expunit.Expect.expectMilliseconds(TestRunner) at frysk.expunit.Expect.expect(TestRunner) at frysk.expunit.Expect.expect(TestRunner) at frysk.expunit.Expect.expect(TestRunner) at frysk.expunit.Expect.expect(TestRunner) at frysk.hpd.TestPrint.testHpdArray(TestRunner) at frysk.junit.Runner.runCases(TestRunner) at frysk.junit.Runner.runArchCases(TestRunner) at frysk.junit.Runner.runTestCases(TestRunner) at TestRunner.main(TestRunner) There were 3 failures: 1) testSliceAddressSpace(frysk.proc.live.TestByteBuffer)junit.framework.AssertionFailedError: unexpected signal Sig_IO at frysk.testbed.AttachedSelf$2.signal(TestRunner) at frysk.sys.Wait.wait(TestRunner) at frysk.sys.Wait.wait(TestRunner) at frysk.testbed.AttachedSelf.(TestRunner) at frysk.proc.live.TestByteBuffer.setUp(TestRunner) at frysk.junit.Runner.runCases(TestRunner) at frysk.junit.Runner.runArchCases(TestRunner) at frysk.junit.Runner.runTestCases(TestRunner) at TestRunner.main(TestRunner) 2) testVarOutOfScope(frysk.rt.TestDisplayValue)junit.framework.AssertionFailedError: Variable value at first breakpoint expected:<5> but was:<0> at frysk.rt.TestDisplayValue.testVarOutOfScope(TestRunner) at frysk.junit.Runner.runCases(TestRunner) at frysk.junit.Runner.runArchCases(TestRunner) at frysk.junit.Runner.runTestCases(TestRunner) at TestRunner.main(TestRunner) 3) testValues(frysk.rt.TestFrameDebugInfo)junit.framework.AssertionFailedError: Value expected:<0> but was:<3> at frysk.rt.TestFrameDebugInfo.testValues(TestRunner) at frysk.junit.Runner.runCases(TestRunner) at frysk.junit.Runner.runArchCases(TestRunner) at frysk.junit.Runner.runTestCases(TestRunner) at TestRunner.main(TestRunner) FAILURES!!! Tests run: 387, Failures: 3, Errors: 2 Still would be nice to get these fixed. The above is on Fedora Core 6 x86_64 with kernel 2.6.20-1.2962.fc6 Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: lost-testbed-file.patch Type: text/x-patch Size: 4293 bytes Desc: not available URL: From mark@klomp.org Thu Jul 26 07:11:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Thu, 26 Jul 2007 07:11:00 -0000 Subject: new command fexe In-Reply-To: <46A7793B.1070207@redhat.com> References: <469E678F.1020101@redhat.com> <1184834265.3629.21.camel@dijkstra.wildebeest.org> <46A7793B.1070207@redhat.com> Message-ID: <1185433886.3630.22.camel@dijkstra.wildebeest.org> Hi Andrew, On Wed, 2007-07-25 at 12:24 -0400, Andrew Cagney wrote: > cagney@nettle$ cp /bin/bash /tmp > cagney@nettle$ /tmp/bash > cagney@nettle$ cp /bin/bash /tmp/a-very-long-file > cagney@nettle$ mv !$ /tmp/bash > mv /tmp/a-very-long-file /tmp/bash > cagney@nettle$ /home/scratch/frysk/native/frysk-core/frysk/bindir/fexe $$ > null > cagney@nettle$ /home/scratch/frysk/native/frysk-core/frysk/bindir/fexe -v $$ > 3905 null /tmp/bash4]setspeed (deleted) > cagney@nettle$ Very interesting. It doesn't really depend on the something very-long, just something with a longer path than the original. Also, it goes away if in between any of these commands you actually examine /proc/$$/exe first. Looking at the kernel code I couldn't immediately find a fix, but it is at least hinted at in fs/dcache.c that the result looks ugly for things like open files in /proc that get deleted by a move. It also say "We could be more polite about it, though." But I didn't see some simple fix. But this highlights the fact that it really is a fake symlink. Which you cannot really trust at all except for displaying something human readable as needed in the gui, but you shouldn't use it for trying to get at the Elf image as done in the core, in that case you have to open the original /proc/pid/exe directly. So we really need 2 interfaces here to satisfy the 2 different ways getExe() is used. One to get the symlink name to display and one to get at the file to open to get the actual exe image (even when the original exe got moved or deleted). Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Thu Jul 26 07:24:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Thu, 26 Jul 2007 07:24:00 -0000 Subject: [patch] Stat vs slurp vs linux 2.6.22 In-Reply-To: <46A76EDB.1080400@redhat.com> References: <1185363024.3597.16.camel@dijkstra.wildebeest.org> <46A75077.2020706@redhat.com> <1185375592.3597.40.camel@dijkstra.wildebeest.org> <46A76EDB.1080400@redhat.com> Message-ID: <1185434653.3630.34.camel@dijkstra.wildebeest.org> Hi Andrew, On Wed, 2007-07-25 at 11:40 -0400, Andrew Cagney wrote: > Mark Wielaard wrote: > >>> It might make sense to rewrite slurp as a normal java class so these > >>> cross C/Java error handling issues. Is there a reason for slurp to have > >>> to be written in C/CNI? > >>> > >> -> memory pressure; notice how it does a callback > >> -> performance > >> > > Interesting. It does feel a little like a premature optimization though, > > seeing that we are finding bugs in it because of the Java/C/CNI mixture > > of error and memory handling that are hard to track down. > > > We're talking here about Scan, not slurp; the first implementation did > use File et.al. It was changed from java to a builder to reduce memory > pressure and produced a dramatic performance boost. > > Scan, by not double allocating memory read also keeps memory pressure down. Does Scan refer to some old class used before slurp? I couldn't easily track the history in CVS since the files seem to have moved a lot. Or are you talking about the scanInt() and scanLong() functions of slurp? In the later case there is no reason why reading the whole thing into a buffer and then extracting the data out of it would be more or less efficient in some other language. If you would really like to keep the memory pressure down you could even just use a DataInputStream so you don't need to read in a buffer at all and get reading primitive datatypes for free. > Going forward, the less memory dropped on the floor by the core, the > easier it will be to push more of this into C++. I am not sure I follow what you are saying here. I agree that writing memory efficient code is good, but I don't see where C++ comes in. Since most of frysk is actually written in java, we want to provide a higher level interface in java for the core, most of the nasty bugs come from the C side with memory resource corruption and exception handling errors and we might want to look at using JNI instead of CNI it makes sense to rely less on C instead of more to make things easier for us all and safer for the user. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From roland@redhat.com Thu Jul 26 09:16:00 2007 From: roland@redhat.com (Roland McGrath) Date: Thu, 26 Jul 2007 09:16:00 -0000 Subject: utrace-devel@redhat.com mailing list Message-ID: <20070726091544.C681F4D058D@magilla.localdomain> A few people not involved with this project or the other one asked for a mailing list devoted to utrace development, so I've created one. This list will now be the main place to discuss bugs in utrace, questions about using the utrace in-kernel APIs, porting utrace, integrating utrace, and writing general-purpose reusable utrace-based components that can be employed by more than one particular tracing engine. The list will be open to all subscribers, archives are public, and posting is not restricted to members (unless noise becomes a problem, then it may be). Subscription details at: https://www.redhat.com/mailman/listinfo/utrace-devel Please avoid cross-posting. You can always refer people on another project list to a utrace-devel thread they might like to join, or vice versa. Thanks, Roland From kris.van.hees@oracle.com Thu Jul 26 13:23:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Thu, 26 Jul 2007 13:23:00 -0000 Subject: Problem with getExe and testInsertedBreakpoint Message-ID: <20070726132332.GD20459@ca-server1.us.oracle.com> Recently, a problem has surfaced related to getExe() in relation to core files and its use in the testInsertedBreakpoint() test. Specifically, the core file seems to store the first 79 characters of the full executable pathname only. This results in truncation in cases where the frysk build tree is located fairly far down a directory hierarchy (which is a implicit test in itself), and the testInsertedBreakpoint test tries to read the executable using a truncated (and thus invalid) executable path name. As far as the test is concerned, I think it might be easiest to simply use the (known) path name to the executable name directly because this particular test is *not* verifying whether the getExe() processing works. Avoiding this problem altogether in this test will at least avoid the current problem. Whether this problem can be resolved in general remains to be seen. If the executable name is simply not available, there is nothing we can do. However, there might be a tiny hope that we can get to the executable path name anyway. Running 'strings' on the core files I checked displays the untruncated version twice. I'm currently looking whether there is a clean, dependable way to get to that information. Cheers, Kris From mark@klomp.org Thu Jul 26 13:58:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Thu, 26 Jul 2007 13:58:00 -0000 Subject: Problem with getExe and testInsertedBreakpoint In-Reply-To: <20070726132332.GD20459@ca-server1.us.oracle.com> References: <20070726132332.GD20459@ca-server1.us.oracle.com> Message-ID: <1185458316.3630.57.camel@dijkstra.wildebeest.org> Hi Kris, On Thu, 2007-07-26 at 06:23 -0700, Kris Van Hees wrote: > Recently, a problem has surfaced related to getExe() in relation to core > files and its use in the testInsertedBreakpoint() test. Specifically, > the core file seems to store the first 79 characters of the full > executable pathname only. This results in truncation in cases where the > frysk build tree is located fairly far down a directory hierarchy (which > is a implicit test in itself), and the testInsertedBreakpoint test tries > to read the executable using a truncated (and thus invalid) executable > path name. > > As far as the test is concerned, I think it might be easiest to simply > use the (known) path name to the executable name directly because this > particular test is *not* verifying whether the getExe() processing > works. Avoiding this problem altogether in this test will at least > avoid the current problem. Nice catch. But the test case seems to actually be testing the wrong thing. It should test the symbols found in the actual core file, but it tries to open Proc.getExe() which points to the (truncated) path of the executable that created the core file. > Whether this problem can be resolved in general remains to be seen. If > the executable name is simply not available, there is nothing we can do. > However, there might be a tiny hope that we can get to the executable > path name anyway. Running 'strings' on the core files I checked > displays the untruncated version twice. I'm currently looking whether > there is a clean, dependable way to get to that information. As pointed out earlier today in the fexe command thread it would be nice to split getExe() into 2 semantically different things. 1) String Proc.getExeName(); Which provides the possible name of the executable. Using /proc/pid/exe symlink following or the name stored in the core file. Both might not be completely accurate because they were truncated or moved. This should be used to display to the user what command was run. 2) File Proc.getExeFile(); Which provides the actual file path to open to get at the elf image (/proc/pid/exe opened "raw", not following the symlink, or the actual File that the core file was loaded from). Does that make sense/would that work? Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pmachata@redhat.com Thu Jul 26 14:57:00 2007 From: pmachata@redhat.com (Petr Machata) Date: Thu, 26 Jul 2007 14:57:00 -0000 Subject: ltrace Message-ID: <46A8B656.50906@redhat.com> Hi, I committed first stab on ltrace for frysk, dubbed fltrace. The output is very rudimentary, but should at least print out library function called from the executable itself. fltrace is only known to work on i386 for non-PIE ELF binaries, and as far as I know it currently doesn't work well with threads. I'll work to get it more feature-full during the summer. PM -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From pmuldoon@redhat.com Thu Jul 26 15:00:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 26 Jul 2007 15:00:00 -0000 Subject: Problem with getExe and testInsertedBreakpoint In-Reply-To: <20070726132332.GD20459@ca-server1.us.oracle.com> References: <20070726132332.GD20459@ca-server1.us.oracle.com> Message-ID: <46A8B6DE.6080305@redhat.com> Kris Van Hees wrote: > Recently, a problem has surfaced related to getExe() in relation to core > files and its use in the testInsertedBreakpoint() test. Specifically, > the core file seems to store the first 79 characters of the full > executable pathname only. For context here. The executable name is usually stored in two places, both in the same note: eu-readelf -n core.2843 Note segment of 584 bytes at offset 0x294: Owner Data size Type CORE 124 PRPSINFO state: T (84), zombie: 49, nice: 48 flags: 00400000, uid: 500, gid: 500 pid: 2843, ppid: 2807, pgrp: 2843, sid: 2807 fname: funit-child args: /home/pmuldoon/frysk_bin/frysk-core/frysk/pkglibdir/funit-child 10000 --busy-lo The first is fname, and the second ... assuming no tinkering with the args, is arg[0] in the args list. In the struct elf_prpsinfo, these two are defined as char pr_fname[16]; /* Filename of executable */ char pr_psargs[80]; /* Initial part of arg list */ So the length is limited in the notes section in the core file. There is nothing fcore, or gcore can do to overcome this. The fcore command uses automatic executable location, which tries to find the executable from arg[0], or /usr/bin, or /bin. This is because there are two constructors in dead/LinuxHost. One that just takes just a core file and tries to find the core file itself (with hopefully build-id patches in the future), and one that takes a core file and its corresponding executable. From an api point of view, the latter will always be more accurate. Perhaps fcore and other core file utilities need to utilize the second constructor? Personally I would prefer this approach. > This results in truncation in cases where the > frysk build tree is located fairly far down a directory hierarchy (which > is a implicit test in itself), and the testInsertedBreakpoint test tries > to read the executable using a truncated (and thus invalid) executable > path name. > The truncation is always going to occur in that case :( > As far as the test is concerned, I think it might be easiest to simply > use the (known) path name to the executable name directly because this > particular test is *not* verifying whether the getExe() processing > works. Avoiding this problem altogether in this test will at least > avoid the current problem. > The second constructor in dead/LinuxHost will satisfy that. Anyway, good catch. Regards Phil From swagiaal@redhat.com Thu Jul 26 15:02:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Thu, 26 Jul 2007 15:02:00 -0000 Subject: ltrace In-Reply-To: <46A8B656.50906@redhat.com> References: <46A8B656.50906@redhat.com> Message-ID: <46A8B771.5050804@redhat.com> Petr Machata wrote: > Hi, > > I committed first stab on ltrace for frysk, dubbed fltrace. Sweet! From pmuldoon@redhat.com Thu Jul 26 15:03:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 26 Jul 2007 15:03:00 -0000 Subject: Problem with getExe and testInsertedBreakpoint In-Reply-To: <46A8B6DE.6080305@redhat.com> References: <20070726132332.GD20459@ca-server1.us.oracle.com> <46A8B6DE.6080305@redhat.com> Message-ID: <46A8B7A7.8050502@redhat.com> Phil Muldoon wrote: > Perhaps fcore and other core file utilities need to utilize the second > constructor? Sorry made a mistake here. fcore should be fstack, fhpd, and source window. From scox@redhat.com Thu Jul 26 15:13:00 2007 From: scox@redhat.com (Stan Cox) Date: Thu, 26 Jul 2007 15:13:00 -0000 Subject: shared object addressing Message-ID: <1185462799.14921.23.camel@multics.rdu.redhat.com> The addressing oddity I mentioned in the meeting appears to occur with shared objects. For example break main in the following sets the break in a shared object as opposed to in main: fhpd tstctors0.x Attached to process 10787 (fhpd) break main breakpoint 0 (fhpd) go (fhpd) Breakpoint 0 main where #0 0x0000000000400808 in __libc_csu_init () #1 0x0000003c54a1daa4 in __libc_start_main () #2 0x0000000000400639 in __gxx_personality_v0@@CXXABI_1.3 () (fhpd) Also disassembling a shared object (a printf call) encounters a snag: fhpd hello.x # hello world program Attached to process 10538 (fhpd) break main breakpoint 0 (fhpd) go (fhpd) Breakpoint 0 main disassemble 0x400498 push %rbp 0x400499 mov %rsp,%rbp *0x40049c mov $0x4005a8,%edi 0x4004a1 callq 0x400398 0x4004a6 leaveq 0x4004a7 retq (fhpd) stepi Task stopped at line 4 in file /home/scox/frysk/bld/x86_64-redhat-linux/hello.c (fhpd) stepi Task stopped at address 0x4195224 (fhpd) disassemble ptrace: Input/output error (pt 0x2, pid 10538, addr 0x0, data 0x0) at frysk.sys.Ptrace$AddressSpace.peek(fhpd) at frysk.proc.live.AddressSpaceByteBuffer$PeekRequest.execute(fhpd) at frysk.event.Request$Handler.execute(fhpd) at frysk.event.EventLoop.runEventLoop(fhpd) at frysk.event.EventLoop.run(fhpd) Internal debugger error: -------------- next part -------------- A non-text attachment was scrubbed... Name: tstctors0.cc Type: text/x-c++src Size: 353 bytes Desc: not available URL: From pmuldoon@redhat.com Thu Jul 26 15:35:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 26 Jul 2007 15:35:00 -0000 Subject: Problem with getExe and testInsertedBreakpoint In-Reply-To: <1185458316.3630.57.camel@dijkstra.wildebeest.org> References: <20070726132332.GD20459@ca-server1.us.oracle.com> <1185458316.3630.57.camel@dijkstra.wildebeest.org> Message-ID: <46A8BEF5.1080706@redhat.com> Mark Wielaard wrote: > Hi Kris, > > On Thu, 2007-07-26 at 06:23 -0700, Kris Van Hees wrote: > >> Recently, a problem has surfaced related to getExe() in relation to core >> files and its use in the testInsertedBreakpoint() test. Specifically, >> the core file seems to store the first 79 characters of the full >> executable pathname only. This results in truncation in cases where the >> frysk build tree is located fairly far down a directory hierarchy (which >> is a implicit test in itself), and the testInsertedBreakpoint test tries >> to read the executable using a truncated (and thus invalid) executable >> path name. >> >> As far as the test is concerned, I think it might be easiest to simply >> use the (known) path name to the executable name directly because this >> particular test is *not* verifying whether the getExe() processing >> works. Avoiding this problem altogether in this test will at least >> avoid the current problem. >> > > Nice catch. But the test case seems to actually be testing the wrong > thing. It should test the symbols found in the actual core file, but it > tries to open Proc.getExe() which points to the (truncated) path of the > executable that created the core file. > > >> Whether this problem can be resolved in general remains to be seen. If >> the executable name is simply not available, there is nothing we can do. >> However, there might be a tiny hope that we can get to the executable >> path name anyway. Running 'strings' on the core files I checked >> displays the untruncated version twice. I'm currently looking whether >> there is a clean, dependable way to get to that information. >> > > As pointed out earlier today in the fexe command thread it would be nice > to split getExe() into 2 semantically different things. > > 1) String Proc.getExeName(); > Which provides the possible name of the executable. Using /proc/pid/exe > symlink following or the name stored in the core file. Both might not be > completely accurate because they were truncated or moved. This should be > used to display to the user what command was run. > 2) File Proc.getExeFile(); > Which provides the actual file path to open to get at the elf image > (/proc/pid/exe opened "raw", not following the symlink, or the actual > File that the core file was loaded from). > When a core file is modeled in Frysk, it could be a long time from when the core was created. An executable file might not be even available at that time. For this reason there are two layers of meta data built: 1) Basic meta-data. No executable available. No maps can be produced (but address ranges can). No solib tables can be built. No elided segment memory access. At this point we can model the information that is in the core file, and allow access to non-elided sections of the core file. This is basic inspection. Can't do much other than look at memory, and registers. 2) Enhanced meta-data. Executable is available. In this case we can find where the link-map was in the core file when it was dumped by looking at the executable's dynamic segment. We can build a table of what solibs were loaded and mapped into the process when it was dumped, and we can build a "rich" set of maps almost identical to what you would get in /proc/$$/maps. We can now allow elided memory access because we know what solib is at which address, so the host can open that solib and read that memory. This allows sophisticated operations as stack back traces, and so on. At no time is an executable ever loaded into memory during this process, or at any time. It's all simulated via CorefileByteBuffer, and dead/LinuxHost. The process might "look" alive from the interface, but it is well and truly, and probably forever will be, dead ;) All these operations are done by looking at the Elf image on disk. So relying on anything in /proc/$$ won't work in that instance. Hope that sheds a bit of light. Regards Phil From swagiaal@redhat.com Thu Jul 26 15:42:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Thu, 26 Jul 2007 15:42:00 -0000 Subject: Dwarf expertise needed In-Reply-To: <20070721002912.863E14D05BD@magilla.localdomain> References: <20070721002912.863E14D05BD@magilla.localdomain> Message-ID: <46A8C0D2.5030905@redhat.com> > You need to give me a binary, or at least exact compiler version, arch, and > options. A binary is really better, so we can be sure what we are talking > about, can refer to precise addresses and DIEs, etc. > Sounds good, I have attached the executable. I am looking at this address 0x8048386: ./tests/addrscopes -e ../../frysk-core/frysk/pkglibdir/funit-scopes 0x8048386 ./tests/addrscopes: dwarf_getscopes: .debug_ranges section missing Sami -------------- next part -------------- A non-text attachment was scrubbed... Name: funit-scopes Type: application/octet-stream Size: 6653 bytes Desc: not available URL: From cagney@redhat.com Thu Jul 26 16:07:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 26 Jul 2007 16:07:00 -0000 Subject: frysk-core/frysk/symtab ChangeLog SymbolFactor ... In-Reply-To: <20070726143255.32431.qmail@sourceware.org> References: <20070726143255.32431.qmail@sourceware.org> Message-ID: <46A8B58C.5080005@redhat.com> Did we forget to commit the test case? kvanhees@sourceware.org wrote: > CVSROOT: /cvs/frysk > Module name: frysk-core > Changes by: kvanhees@sourceware.org 2007-07-26 14:32:55 > > Modified files: > frysk/symtab : ChangeLog SymbolFactory.java > > Log message: > 2007-07-26 Kris Van Hees > > * SymbolFactory.java (getSymbol): Verify whether the Dwfl and DwflModule > can be retrieved. If not, return UNKNOWN. > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/symtab/ChangeLog.diff?cvsroot=frysk&r1=1.5&r2=1.6 > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/symtab/SymbolFactory.java.diff?cvsroot=frysk&r1=1.1&r2=1.2 > > From cagney@redhat.com Thu Jul 26 16:48:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 26 Jul 2007 16:48:00 -0000 Subject: new command fexe In-Reply-To: <1185433886.3630.22.camel@dijkstra.wildebeest.org> References: <469E678F.1020101@redhat.com> <1184834265.3629.21.camel@dijkstra.wildebeest.org> <46A7793B.1070207@redhat.com> <1185433886.3630.22.camel@dijkstra.wildebeest.org> Message-ID: <46A8D066.2080903@redhat.com> Mark Wielaard wrote: Yes, frysk needs access to at least: -> the exe when the program started -> what might be the exe now with a well defined failure mode (a blank link would be better than "(deleted)" (there's also the last known good exe but that is getting contrived :-) I believe moller's user-land utrace interface makes these available. Andrew > But this highlights the fact that it really is a fake symlink. Which you > cannot really trust at all except for displaying something human > readable as needed in the gui, but you shouldn't use it for trying to > get at the Elf image as done in the core, in that case you have to open > the original /proc/pid/exe directly. So we really need 2 interfaces here > to satisfy the 2 different ways getExe() is used. One to get the symlink > name to display and one to get at the file to open to get the actual exe > image (even when the original exe got moved or deleted). > > Cheers, > > Mark > From cagney@redhat.com Thu Jul 26 17:09:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 26 Jul 2007 17:09:00 -0000 Subject: ltrace In-Reply-To: <46A8B656.50906@redhat.com> References: <46A8B656.50906@redhat.com> Message-ID: <46A8D56E.7040103@redhat.com> Cool. Have you considered folding this this to the current ftrace program so we've a tool that can trace both syscalls and library functions? As an aside, the direction here is for ftrace to, by default, just report trace process fork/clone events. Then if the user specifies syscalls (or library calls) to trace then it enables them. Andrew Petr Machata wrote: > Hi, > > I committed first stab on ltrace for frysk, dubbed fltrace. The output > is very rudimentary, but should at least print out library function > called from the executable itself. > > fltrace is only known to work on i386 for non-PIE ELF binaries, and as > far as I know it currently doesn't work well with threads. I'll work to > get it more feature-full during the summer. > > PM > > From cagney@redhat.com Thu Jul 26 17:45:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 26 Jul 2007 17:45:00 -0000 Subject: Broken build In-Reply-To: <1185431764.3630.7.camel@dijkstra.wildebeest.org> References: <20070726034913.GB20459@ca-server1.us.oracle.com> <1185431764.3630.7.camel@dijkstra.wildebeest.org> Message-ID: <46A8DDDD.6090600@redhat.com> Mark Wielaard wrote: > I tried to reconstruct this commit and came up with the following: > 2007-07-26 Mark Wielaard > > * DaemonBlockedAtEntry.java: New file. > > weird; thanks. Only tweak was to make more fields private. Kris, just fyi, change log entries such as: * TestProcTasksObserver.java: Update; TaskSet moved from frysk.testbed.TestLib to frysk.testbed.TaskSet. * TestRun.java: Ditto. * TestTaskObserverBlocked.java: Ditto. * TestTaskClonedObserver.java: Update; Fibonacci moved from frysk.testbed.TestLib to separate class. * TestTaskObserverBlocked.java: Ditto. * TestTaskForkedObserver.java: Ditto. being separated by blank lines, normally denote separate commits (and here has no bearing). Can we try to post what is relevant? Andrew From mark@klomp.org Thu Jul 26 18:57:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Thu, 26 Jul 2007 18:57:00 -0000 Subject: Problem with getExe and testInsertedBreakpoint In-Reply-To: <46A8BEF5.1080706@redhat.com> References: <20070726132332.GD20459@ca-server1.us.oracle.com> <1185458316.3630.57.camel@dijkstra.wildebeest.org> <46A8BEF5.1080706@redhat.com> Message-ID: <1185476234.13705.22.camel@dijkstra.wildebeest.org> Hi Phil, On Thu, 2007-07-26 at 10:34 -0500, Phil Muldoon wrote: > When a core file is modeled in Frysk, it could be a long time from when > the core was created. An executable file might not be even available at > that time. For this reason there are two layers of meta data built: > > 1) Basic meta-data. No executable available. No maps can be produced > (but address ranges can). No solib tables can be built. No elided > segment memory access. At this point we can model the information that > is in the core file, and allow access to non-elided sections of the core > file. This is basic inspection. Can't do much other than look at memory, > and registers. What does "elided" mean in this context? > 2) Enhanced meta-data. Executable is available. In this case we can find > where the link-map was in the core file when it was dumped by looking at > the executable's dynamic segment. We can build a table of what solibs > were loaded and mapped into the process when it was dumped, and we can > build a "rich" set of maps almost identical to what you would get in > /proc/$$/maps. We can now allow elided memory access because we know > what solib is at which address, so the host can open that solib and read > that memory. This allows sophisticated operations as stack back traces, > and so on. OK, so does this mean not all code segments might be available in the core elf file itself, but that you need to cross-reference them always against the actual executable (but you aren't guaranteed access to the orgininal executable since even the core file itself doesn't have a reliable link to it)? My question really is what about code segments that are modified (as we do in the testcase that Kris pointed at)? Or maybe more realistically, what about code segments generated dynamically by the process (like in the case of a just in time, hotspot, compiler)? Finally, how does the rest of the core get access to these code segments? For example in this testcase or in the DebugInfo, access to the Elf object for the Proc is obtained by doing new Elf(proc.getExe()). But since for core Procs that would give the (possible not full, or no longer existing) path to the original executable that seems the wrong approach. And from your explanation I now understand that you shouldn't do it this way (need to audit the code a bit more to find all cases where this happens), but go through the getMaps() interface and create a Dwfl from that. > Hope that sheds a bit of light. Yes, thanks! Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pmuldoon@redhat.com Thu Jul 26 19:32:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 26 Jul 2007 19:32:00 -0000 Subject: Problem with getExe and testInsertedBreakpoint In-Reply-To: <1185476234.13705.22.camel@dijkstra.wildebeest.org> References: <20070726132332.GD20459@ca-server1.us.oracle.com> <1185458316.3630.57.camel@dijkstra.wildebeest.org> <46A8BEF5.1080706@redhat.com> <1185476234.13705.22.camel@dijkstra.wildebeest.org> Message-ID: <46A8F6BD.90805@redhat.com> Mark Wielaard wrote: > Hi Phil, > > On Thu, 2007-07-26 at 10:34 -0500, Phil Muldoon wrote: > > > What does "elided" mean in this context? > With apologies to Roland who coined and explained these terms to me. Any errors I make here are mine, but: elided means the segment is recorded in the program headers, but was not included in the core file dump (ie filesz = 0, memsz > 0). Segments are elided when they can be reconstructed after a core file dump (ie segments that have not been written to). included means both the program header and the segment itself is written (ie filesz >0, memsz >0 but filesz is never more than memsz) omitted means neither the program header entry or the segment is written for that segment (ie in future it will not exist in core file reconstruction). > >> 2) Enhanced meta-data. Executable is available. In this case we can find >> where the link-map was in the core file when it was dumped by looking at >> the executable's dynamic segment. We can build a table of what solibs >> were loaded and mapped into the process when it was dumped, and we can >> build a "rich" set of maps almost identical to what you would get in >> /proc/$$/maps. We can now allow elided memory access because we know >> what solib is at which address, so the host can open that solib and read >> that memory. This allows sophisticated operations as stack back traces, >> and so on. >> > > OK, so does this mean not all code segments might be available in the > core elf file itself, but that you need to cross-reference them always > against the actual executable (but you aren't guaranteed access to the > orgininal executable since even the core file itself doesn't have a > reliable link to it)? > Yes it means that though we might have the code executable segments in the core file, we lose the ability of basic navigation as _all the other executable segments_ might not be there, and certainly not in an easily readable/locatable way. That is why we need the executable for anything other than basic segment and note access, so we can find positional information (like the link_map). The only place the executable name is stored in the core file that we can get to reliably is in the elf_prpsinfo notes. > My question really is what about code segments that are modified (as we > do in the testcase that Kris pointed at)? Or maybe more realistically, > what about code segments generated dynamically by the process (like in > the case of a just in time, hotspot, compiler)? > They may or may not be there in the hot-spot case. If the segment has been written to, though, it will be included as it cannot be recreated post core dump. Essentially I suspect a core file of a Java process will be a core file of the JVM with one of the threads being the (user Java) program itself. > Finally, how does the rest of the core get access to these code > segments? For example in this testcase or in the DebugInfo, access to > the Elf object for the Proc is obtained by doing new Elf(proc.getExe()). > The core file code does not care one whit about how the user/implementor uses the information it provides. It cannot, and should not. It would be asking for safety checks beyond the api barrier. It simulates the process image _as close to it can_ to when that process was dumped. It is important to note that that this is still a lot of guessing and calculating and estimating - even if an executable is provided. If no executable was provided or found then that data is just not present in the first place. If you try to access elided data on a basic meta-data core file, it will throw a RuntimeException noting it cannot access that memory address. Proc.getExe() in a Corefile will return the executable string that was found in the notes. > But since for core Procs that would give the (possible not full, or no > longer existing) path to the original executable that seems the wrong > approach. It will provide the information it has. Because core files are traditionally associated with dead or dying processes, the level of paranoia when dealing with a core file should be appropriate. There can be any number of corrupt, badly written, busted, and generally misleading information in there. > And from your explanation I now understand that you shouldn't > do it this way (need to audit the code a bit more to find all cases > where this happens), but go through the getMaps() interface and create a > Dwfl from that. > Right, and I've talked a bit about this and learned that we should have done core files right from that start. Right now (or rather we had) code that makes assumptions that a process is alive and has entries in proc. As I find them, I correct them, or ask the author to correct them. The golden rule here is all information should always come from the Proc or the Task. In the case of maps, it should be getMaps(). In the case of memory, it should be via the Task's memory interface and so on. Hope that helps! Regards Phil From npremji@redhat.com Thu Jul 26 20:24:00 2007 From: npremji@redhat.com (Nurdin Premji) Date: Thu, 26 Jul 2007 20:24:00 -0000 Subject: Fhpd Commands option parsing Message-ID: <46A90311.8080601@redhat.com> I am creating a small option parser based on the getopt option parser for fhpd commands, (okay so the only thing being carried over is the Options class). I want to avoid having to do too many fancy things to add extra options, I like the ability to say parser.addOption and have it know what to do. I'd also like a standard help option for each command that doesn't exit the fhpd when run. I'm making a few assumptions about the possible options for the fhpd internal commands: 1. All options are at the end. I.e. command [parameters ...] [options ...] 2. No option has arguments. Are these safe assumptions? Are there more I can count on? From cagney@redhat.com Thu Jul 26 20:36:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 26 Jul 2007 20:36:00 -0000 Subject: Fhpd Commands option parsing In-Reply-To: <46A90311.8080601@redhat.com> References: <46A90311.8080601@redhat.com> Message-ID: <46A90604.4070608@redhat.com> Nurdin Premji wrote: > I am creating a small option parser based on the getopt option parser > for fhpd commands, (okay so the only thing being carried over is the > Options class). I want to avoid having to do too many fancy things to > add extra options, I like the ability to say parser.addOption and have > it know what to do. I'd also like a standard help option for each > command that doesn't exit the fhpd when run. > > I'm making a few assumptions about the possible options for the fhpd > internal commands: > 1. All options are at the end. > I.e. command [parameters ...] [options ...] > 2. No option has arguments. > > Are these safe assumptions? Are there more I can count on? > Well you can delete #2 :-( print -x -format x from memory (print "x" negated as hex?). An equivalent to "--" to halt option parsing might help. Andrew From pmachata@redhat.com Thu Jul 26 20:43:00 2007 From: pmachata@redhat.com (Petr Machata) Date: Thu, 26 Jul 2007 20:43:00 -0000 Subject: ltrace In-Reply-To: <46A8D56E.7040103@redhat.com> References: <46A8B656.50906@redhat.com> <46A8D56E.7040103@redhat.com> Message-ID: <46A90812.2040208@redhat.com> Andrew Cagney wrote: > Cool. > > Have you considered folding this this to the current ftrace program so > we've a tool that can trace both syscalls and library functions? Yes, I have. I mostly wanted to get familiar with the framework, so I made it tool on its own. I will work on merging the two, fltrace is mostly copied from ftrace anyway. Btw, does it make sense, or is it feasible from frysk's architecture standpoint, to add libcall event to frysk monitor? (That gui thing with time axis and ticks.) I haven't done any investigation in this matter, it just sits at the back of my brain since I started tinkering with frysk... PM From cagney@redhat.com Thu Jul 26 22:30:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 26 Jul 2007 22:30:00 -0000 Subject: which elf symbol? In-Reply-To: <20070726022738.4350E4D058D@magilla.localdomain> References: <20070726022738.4350E4D058D@magilla.localdomain> Message-ID: <46A9209F.30103@redhat.com> Roland McGrath wrote: > I reduced your report to an isolated test case of trivial assembly. I've > slightly modified addr2line so I'm using it as a test program with -e on > the .o file to just print out the results of dwfl_module_addrsym. > Please help me adjust this test case to match (or also include) cases > equivalent to what you are seeing. > What about a case like: symbol: nop unsized_symbol: nop .size symbol, .-symbol 1: the closest symbol is unsized_symbol, but that is probably not the intent. > >> local_st_size_0: // this symbol has no size >> >> global_outer: >> nop >> local_in_global: >> nop >> .size local_in_global, .-local_in_global >> nop >> <> >> .size global_outer, .-global_outer >> >> that is global_outer contains a nested symbol but the "pc" is beyond >> that back in the outer/global symbol. >> >> I'm guessing that "global_outer" should be returned. Currently >> local_st_size_0 is returned :-( >> > > Arguably the answer should be no symbol, since the address is past the end > of the nearest symbol's size. > the xample was unclear <> is ment to be within global_outer; your test did that. > This is t1 in my test case, looking at pc=0x2. I get t1_global_outer+0x2 > from addrsym here, so my case must differ from what you tried here. > Can you figure out how they differ? > > I'm looking. >> This is the no-symbol case, there is a hole in the memory where there is >> no valid symbol vis: >> >> local_st_size_0: // this symbol has no size >> >> global_symbol: >> nop >> nop >> .size global_symbol, .-global_symbol >> >> << you are here >> >> >> I'm guessing it should not get a symbol at all (the [unknown]). It >> currently gets the nearest unsized symbol. >> > > This is t2 in my test case, looking at pc=0x6a. > I get t2_local_st_size_0+0x2 here. Go figure. > > You wrote your marker in a different place, but there is no address > difference between the context before the .size directive in the assembly > source and the context after it. So unless I'm misunderstanding what cases > you intended to describe, this should be the same case as t1. (It doesn't > really matter that there is a local symbol nearby, since the PC of interest > is unambiguous outside that symbol's address range.) > > I'll look into why they come out differently, which might relate to some > other symptom. I also agree that the right answer is no symbol. > > ok. >> These are cases where there is a nested symbol within a sized symbol vis: >> >> global_after_0: >> nop >> local_0_in_global: >> << you are here >> >> nop >> .size global_after_0, .-global_after_0 >> >> here, since the PC is exactly at the unsized local symbol I'm guessing >> that it should return that. It currently gets the containing sized symbol. >> > > This is my t3. I get t3_global_after_0+0x1 as you say. This is the > intended behavior, not a bug. We can discuss what the behavior should be. > > /* Handwritten assembly symbols sometimes have no st_size. > If no symbol with proper size includes the address, we'll > use the closest one that is in the same section as ADDR. */ > > Yes, agreed. The sized symbol should trump the unsized one. > Usually size-0 symbols are local assembler labels, and sized symbols are > the entry points. For things like backtraces, people usually want to see > the symbol names for the entry points (plus offsets) rather than the local > labels that often have unhelpful names. That's what I had in mind when I > wrote that. addrsym started out as addrname, which does not pass back an > offset and only used for "what function is this in?" kinds of queries. For > that, it clearly makes more sense to prefer the containing sized symbol. > > However, for things like disassembly, people probably would like to see the > local label names, or perhaps both names. > > That's an interesting option; it would better reflect exactly what is in the file. Andrew > Thanks, > Roland > From pearly.zhao@oracle.com Fri Jul 27 02:16:00 2007 From: pearly.zhao@oracle.com (Zhao Shujing) Date: Fri, 27 Jul 2007 02:16:00 -0000 Subject: [patch] fix bug 4612 Message-ID: <1185502689.4051.15.camel@linux-pzhao.site> Hi, Please take a look at the attached patch. It is to fix bug 4612. It also does: - Make the column display of memory window synchronous with the fromBox when adjust the fromSpin. - Do the same to disassembly window when adjust the toSpin. Thanks Pearly -------------- next part -------------- A non-text attachment was scrubbed... Name: pearly-4612.patch Type: text/x-patch Size: 5105 bytes Desc: URL: From mark@klomp.org Fri Jul 27 10:00:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Fri, 27 Jul 2007 10:00:00 -0000 Subject: Problem with getExe and testInsertedBreakpoint In-Reply-To: <46A8F6BD.90805@redhat.com> References: <20070726132332.GD20459@ca-server1.us.oracle.com> <1185458316.3630.57.camel@dijkstra.wildebeest.org> <46A8BEF5.1080706@redhat.com> <1185476234.13705.22.camel@dijkstra.wildebeest.org> <46A8F6BD.90805@redhat.com> Message-ID: <1185530388.3588.51.camel@dijkstra.wildebeest.org> Hi Phil, On Thu, 2007-07-26 at 14:32 -0500, Phil Muldoon wrote: > With apologies to Roland who coined and explained these terms to me. Any > errors I make here are mine, but: > > elided means the segment is recorded in the program headers, but was not > included in the core file dump (ie filesz = 0, memsz > 0). Segments are > elided when they can be reconstructed after a core file dump (ie > segments that have not been written to). > > included means both the program header and the segment itself is written > (ie filesz >0, memsz >0 but filesz is never more than memsz) > > omitted means neither the program header entry or the segment is written > for that segment (ie in future it will not exist in core file > reconstruction). Aha, that also explains the meaning of the new kernel /proc/sys sysctrl parameters fs.binfmt_elf.dumpwhole_segments to get all text sections included and fs.binfmt_elf.dump_elf_headers to get partial text sections that I saw Roland added. Does fcore have some similar parameters? > Yes it means that though we might have the code executable segments in > the core file, we lose the ability of basic navigation as _all the other > executable segments_ might not be there, and certainly not in an easily > readable/locatable way. That is why we need the executable for anything > other than basic segment and note access, so we can find positional > information (like the link_map). The only place the executable name is > stored in the core file that we can get to reliably is in the > elf_prpsinfo notes. Right, and elf_prpsinfo only allows for truncated executable names (16 chars). Bleah. So something like BuildID is really badly needed to present the user with something that is more often usable I guess. I saw that the BuildID support proposal was approved as one of the Fedora 8 Features: http://fedoraproject.org/wiki/Releases/FeatureBuildId http://fedoraproject.org/wiki/Releases/8/FeatureList Will it be possible for frysk to also support that in the Fedora 8 timeframe? > > My question really is what about code segments that are modified (as we > > do in the testcase that Kris pointed at)? Or maybe more realistically, > > what about code segments generated dynamically by the process (like in > > the case of a just in time, hotspot, compiler)? > > > > They may or may not be there in the hot-spot case. If the segment has > been written to, though, it will be included as it cannot be recreated > post core dump. OK, and I assume the same would be true for any code segments that were altered through ptrace poke? > > And from your explanation I now understand that you shouldn't > > do it this way (need to audit the code a bit more to find all cases > > where this happens), but go through the getMaps() interface and create a > > Dwfl from that. > > > Right, and I've talked a bit about this and learned that we should have > done core files right from that start. Right now (or rather we had) code > that makes assumptions that a process is alive and has entries in proc. > As I find them, I correct them, or ask the author to correct them. The > golden rule here is all information should always come from the Proc or > the Task. In the case of maps, it should be getMaps(). In the case of > memory, it should be via the Task's memory interface and so on. Thanks. I filed bug #4852 to clean up the code where I abused it and will go through the other stuff in the core listed there that uses the wrong approach (I know I just copied what I did from some other existing example, so it is good to get this fully cleaned up). > Hope that helps! It helped greatly. Thanks for sharing. Some of the things you said suddenly made me see the bigger picture and connect the dots. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pmuldoon@redhat.com Fri Jul 27 13:41:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 27 Jul 2007 13:41:00 -0000 Subject: Problem with getExe and testInsertedBreakpoint In-Reply-To: <1185530388.3588.51.camel@dijkstra.wildebeest.org> References: <20070726132332.GD20459@ca-server1.us.oracle.com> <1185458316.3630.57.camel@dijkstra.wildebeest.org> <46A8BEF5.1080706@redhat.com> <1185476234.13705.22.camel@dijkstra.wildebeest.org> <46A8F6BD.90805@redhat.com> <1185530388.3588.51.camel@dijkstra.wildebeest.org> Message-ID: <46A9F5FC.6050007@redhat.com> Mark Wielaard wrote: > Hi Phil, > > On Thu, 2007-07-26 at 14:32 -0500, Phil Muldoon wrote: > > > Aha, that also explains the meaning of the new kernel /proc/sys sysctrl > parameters fs.binfmt_elf.dumpwhole_segments to get all text sections > included and fs.binfmt_elf.dump_elf_headers to get partial text sections > that I saw Roland added. Does fcore have some similar parameters? > > Yup, fcore -a dump all possible segments. However that is not the default. That has been there since fcore was written because I perhaps made the brave assumption that in userland core dumps we can hang around and dump more segments as the process is "fine". In kernel core dumps I think the aim it so do this all as quickly as possible and clobber the process. > Right, and elf_prpsinfo only allows for truncated executable names (16 > chars). Bleah. So something like BuildID is really badly needed to > present the user with something that is more often usable I guess. I saw > that the BuildID support proposal was approved as one of the Fedora 8 > Features: http://fedoraproject.org/wiki/Releases/FeatureBuildId > http://fedoraproject.org/wiki/Releases/8/FeatureList > Will it be possible for frysk to also support that in the Fedora 8 > timeframe? > > Given that there is a lot to do, and not enough of us to do it, I've taken the rather (perhaps cheeky) approach of letting Jan and Roland thrash out the details, then pick it up and incorporate it when done. I already owe a Roland an answer to the partially elided segment question and Frysk. > OK, and I assume the same would be true for any code segments that were > altered through ptrace poke? > > I'm not sure of kernel mechanics. The core dump class just looks at the the bits in /proc/$$/maps to see if it has been written to. > Thanks. I filed bug #4852 to clean up the code where I abused it and > will go through the other stuff in the core listed there that uses the > wrong approach (I know I just copied what I did from some other existing > example, so it is good to get this fully cleaned up). > > >> Hope that helps! >> > > It helped greatly. Thanks for sharing. Some of the things you said > suddenly made me see the bigger picture and connect the dots. > > Awesome, glad to be of help Regards Phil From swagiaal@redhat.com Fri Jul 27 14:40:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Fri, 27 Jul 2007 14:40:00 -0000 Subject: ltrace In-Reply-To: <46A90812.2040208@redhat.com> References: <46A8B656.50906@redhat.com> <46A8D56E.7040103@redhat.com> <46A90812.2040208@redhat.com> Message-ID: <46AA03CB.50008@redhat.com> > Btw, does it make sense, or is it feasible from frysk's architecture > standpoint, to add libcall event to frysk monitor? (That gui thing with > time axis and ticks.) I haven't done any investigation in this matter, > it just sits at the back of my brain since I started tinkering with frysk... > Yes! for sure... it would give you a chance to explore that code; I would love to hear comments about that api. But if you want me to do it just file a bug. Sami Wagiaalla From pmachata@redhat.com Fri Jul 27 14:58:00 2007 From: pmachata@redhat.com (Petr Machata) Date: Fri, 27 Jul 2007 14:58:00 -0000 Subject: ltrace In-Reply-To: <46AA03CB.50008@redhat.com> References: <46A8B656.50906@redhat.com> <46A8D56E.7040103@redhat.com> <46A90812.2040208@redhat.com> <46AA03CB.50008@redhat.com> Message-ID: <46AA081D.6050601@redhat.com> Sami Wagiaalla wrote: > Yes! for sure... it would give you a chance to explore that code; I > would love to hear comments about that api. But if you want me to do it > just file a bug. Nice, will take a look at this later. I'll reach you on chat if I have more concrete questions. > Sami Wagiaalla PM -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From scox@redhat.com Fri Jul 27 15:02:00 2007 From: scox@redhat.com (Stan Cox) Date: Fri, 27 Jul 2007 15:02:00 -0000 Subject: dereferencing pointers from frysk.value Message-ID: <1185548524.11775.27.camel@multics.rdu.redhat.com> Currently a class is essentially a list of types and a ByteBuffer of the class contents. It might be nice to dereference a pointer if the pointer's type is char* and display the string. However ClassType just has a pointer, no task to do a task.getMemory() on. DebugInfo has that information. Any suggestions on a nice way to handle this? From cagney@redhat.com Fri Jul 27 15:53:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 27 Jul 2007 15:53:00 -0000 Subject: dereferencing pointers from frysk.value In-Reply-To: <1185548524.11775.27.camel@multics.rdu.redhat.com> References: <1185548524.11775.27.camel@multics.rdu.redhat.com> Message-ID: <46AA1512.3040908@redhat.com> So at present a "pointer" value is seen as a pair: type: pointer->char location: byte-buffer with size==sizeof(void*) and contents=="pointer value" and there's nothing for the "pointer" to point into? It sounds like the Type.toPrint() method should be parameterised with not just the ByteBuffer containing the value, but also the address space or segment[s] to which that value could refer. As an aside, the toPrint method should probably also be parameterized with a base-type formatter so that <> gives <<{ 0x123, 0x456 }>> with these, PrintValue is reduced to: BaseTypeWriter baseTypeWriter = select writer based on -format Value result = cli.parseValue(expression); result.toPrint(outputWriter, task.getMemory(), baseTypeWriter) Andrew For the case of memory, Stan Cox wrote: > Currently a class is essentially a list of types and a ByteBuffer of the > class contents. It might be nice to dereference a pointer if the > pointer's type is char* and display the string. However ClassType just > has a pointer, no task to do a task.getMemory() on. DebugInfo has that > information. Any suggestions on a nice way to handle this? > > > From roland@redhat.com Fri Jul 27 19:04:00 2007 From: roland@redhat.com (Roland McGrath) Date: Fri, 27 Jul 2007 19:04:00 -0000 Subject: Problem with getExe and testInsertedBreakpoint In-Reply-To: Mark Wielaard's message of Friday, 27 July 2007 11:59:47 +0200 <1185530388.3588.51.camel@dijkstra.wildebeest.org> Message-ID: <20070727190347.504344D058D@magilla.localdomain> > Will it be possible for frysk to also support that in the Fedora 8 > timeframe? I intend to have some libdwfl additions for build-id before F8. Those will make it very easy to do something in Frysk. > OK, and I assume the same would be true for any code segments that were > altered through ptrace poke? Correct. The kernel's test is on its internal VM data structures, so it gets any private file mapping that has had some COW happen. Thanks, Roland From swagiaal@redhat.com Fri Jul 27 19:08:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Fri, 27 Jul 2007 19:08:00 -0000 Subject: frysk-core/frysk/stack ChangeLog StackFactory. ... In-Reply-To: <20070727184617.24883.qmail@sourceware.org> References: <20070727184617.24883.qmail@sourceware.org> Message-ID: <46AA42BF.4020609@redhat.com> This broke frysk.util.TestFStack... i am working on a fix. swagiaal@sourceware.org wrote: > CVSROOT: /cvs/frysk > Module name: frysk-core > Changes by: swagiaal@sourceware.org 2007-07-27 18:46:17 > > Modified files: > frysk/stack : ChangeLog StackFactory.java Frame.java > > Log message: > Index: frysk-core/frysk/stack/ChangeLog > +2007-07-27 Sami Wagiaalla > + > + * Frame.java (getLibraryName): New function. > + (toPrint): Now prints library name. > + * StackFactory.java (printRichStackTrace): Now uses > + frame.getLirbaryName > + > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/stack/ChangeLog.diff?cvsroot=frysk&r1=1.32&r2=1.33 > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/stack/StackFactory.java.diff?cvsroot=frysk&r1=1.14&r2=1.15 > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/stack/Frame.java.diff?cvsroot=frysk&r1=1.8&r2=1.9 > > From mcvet@redhat.com Fri Jul 27 19:22:00 2007 From: mcvet@redhat.com (Mike Cvet) Date: Fri, 27 Jul 2007 19:22:00 -0000 Subject: frysk.stepping move Message-ID: <46AA45F2.9000501@redhat.com> All of the stuff in frysk.rt which had to do with the stepping infrastructure has been moved to a new package called frysk.stepping. - Mike From mark@klomp.org Mon Jul 30 12:42:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 30 Jul 2007 12:42:00 -0000 Subject: [patch] LogicalMemoryBuffer In-Reply-To: <1184932926.3611.58.camel@dijkstra.wildebeest.org> References: <1184932926.3611.58.camel@dijkstra.wildebeest.org> Message-ID: <1185799360.3674.13.camel@dijkstra.wildebeest.org> Hi, On Fri, 2007-07-20 at 14:02 +0200, Mark Wielaard wrote: > - Some of the work with our ByteBuffers is somewhat awkward since we > pretend everything is longs. But arrays in java cannot address anything > bigger than a (positive) int. So having offsets and lengths as longs is > somewhat cheating since it will never work in practise. So there is some > casting back and forth. Maybe just change the ByteBuffer methods that > work on arrays to just take ints for offset and length. The following patch does this for ByteBuffers, FileDescriptors and StatelessFile. Now it is possible to catch such issues during compile time instead of during runtime one day when some offset or length is bigger than what fits into an array. This makes implementing the methods that work on byte[] simpler and safer. It also fixes LogicalMemoryBuffer to not set the order explicitly, but lets the caller determine the order. frysk-core/frysk/proc/live/ChangeLog 2007-07-30 Mark Wielaard * AddressSpaceByteBuffer.java (Request): Make length and offset ints. (peek): Likewise. * LinuxTask.java (sendrecMemory): Set memory order. * LogicalMemoryBuffer.java (order): Remove field. (LogicalMemoryBuffer): Don't set order. (peek): Make length and offset ints. (subBuffer): Don't pass order. * MemorySpaceByteBuffer.java (Request): Make length and offset ints. (peek): Likewise. * TestMemorySpaceByteBuffer.java (AsyncPeeks): Make length int. frysk-sys/frysk/sys/ChangeLog 2007-07-30 Mark Wielaard * FileDescriptor.java (read): Make start and length ints. (write): Likewise. * Ptrace.java (peek): Make length and offset ints. * StatelessFile.java (pread): Make start and length ints. (pwrite): Likewise. * TestFileDescriptor.java (IO.op): Likewise. (assertArrayIndexOutOfBounds): Likewise. (testReadOutOfBounds): Likewise. (testWriteOutOfBounds): Likewise. * TestPtrace.java (verifyOutOfBounds): Make length and offset ints. * TestStatelessFile.java: Make start and length ints. * cni/Errno.cxx (verifyBounds): Make start and length ints. * cni/Errno.hxx: Likewise. * cni/FileDescriptor.cxx (read): Make start and length jints. (write): Likewise. * cni/Ptrace.cxx (peek): Make length and offset jints. * cni/StatelessFile.cxx (pread): Make start and length jints. (pwrite): Likewise. frysk-sys/inua/ChangeLog 2007-07-30 Mark Wielaard * eio/ByteBuffer.java (peek): Make off and len ints. (poke): Likewise. (peekFully): Likewise. (pokeFully): Likewise. * eio/MmapByteBuffer.java (peek): Likewise. * eio/cni/MmapByteBuffer.cxx (peek): Likewise. Tested on x86 and x86_64 without regressions. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: eio-buffer.patch Type: text/x-patch Size: 29555 bytes Desc: not available URL: From cagney@redhat.com Mon Jul 30 13:02:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 30 Jul 2007 13:02:00 -0000 Subject: [patch] fix bug 4612 In-Reply-To: <1185502689.4051.15.camel@linux-pzhao.site> References: <1185502689.4051.15.camel@linux-pzhao.site> Message-ID: <46ADE15B.20505@redhat.com> Pearly, The below looks fine. Will you be around tuesday morning (your time?). I'll send you off list some stuff to do with CVS so that you can check this in. Two things to think about though: -> testing; When making fixes we all endeavor to author the test-case up-front so that we can directly demonstrate that the change has the intended effect. -> it looks like there is much code duplication between the Disassembler and Memory windows; an opportunity to refactor? Andrew Zhao Shujing wrote: > Hi, > Please take a look at the attached patch. > It is to fix bug 4612. > It also does: > - Make the column display of memory window synchronous with the fromBox > when adjust the fromSpin. > - Do the same to disassembly window when adjust the toSpin. > > Thanks > Pearly > > ------------------------------------------------------------------------ > > diff -ur frysk-cvs/frysk-gui/frysk/gui/ChangeLog frysk/frysk-gui/frysk/gui/ChangeLog > --- frysk-cvs/frysk-gui/frysk/gui/ChangeLog 2007-07-26 10:11:33.000000000 -0400 > +++ frysk/frysk-gui/frysk/gui/ChangeLog 2007-07-26 10:17:20.000000000 -0400 > @@ -1,3 +1,13 @@ > +2007-07-23 Zhao Shujing > + > + * memory/MemoryWindow.java: fromBox and toBox can be edited. Fixes > + #4612. > + * memory/MemoryWindow.java(handleFromSpin): synchronously display > + column and fromBox when adjust the fromSpin. > + * disassembler/DisassemblyWindow.java: fromBox and toBox can be edited. > + * disassembler/DisassemblyWindow.java(rowAppend): synchronously display > + column and toBox when adjust the toSpin. > + > 2007-07-19 Adam Jocksch > > * sessions/WatchListListener.java: Reformatted. > diff -ur frysk-cvs/frysk-gui/frysk/gui/disassembler/DisassemblyWindow.java frysk/frysk-gui/frysk/gui/disassembler/DisassemblyWindow.java > --- frysk-cvs/frysk-gui/frysk/gui/disassembler/DisassemblyWindow.java 2007-07-26 10:11:33.000000000 -0400 > +++ frysk/frysk-gui/frysk/gui/disassembler/DisassemblyWindow.java 2007-07-26 10:14:53.000000000 -0400 > @@ -345,12 +345,12 @@ > { > public void entryEvent (EntryEvent arg0) > { > - if (arg0.getType() == EntryEvent.Type.CHANGED) > + if (arg0.getType() == EntryEvent.Type.ACTIVATE) > { > if (refreshLock) > return; > > - String str = arg0.getText(); > + String str = fromBox.getText(); > try > { > double d = (double) Long.parseLong(str, 16); > @@ -368,12 +368,12 @@ > { > public void entryEvent (EntryEvent arg0) > { > - if (arg0.getType() == EntryEvent.Type.CHANGED) > + if (arg0.getType() == EntryEvent.Type.ACTIVATE) > { > if (refreshLock) > return; > > - String str = arg0.getText(); > + String str = toBox.getText(); > try > { > double d = (double) Long.parseLong(str, 16); > @@ -592,6 +592,14 @@ > this.lastPath.next(); > if (ins != null) > { > + if (li.hasNext()) > + ins = (Instruction) li.next(); > + else > + { > + this.toSpin.setValue((double) ins.address); > + this.lastKnownTo = ins.address; > + ins = null; > + } > model.setValue(iter, (DataColumnString) cols[1], > ": "); > model.setValue(iter, (DataColumnString) cols[LOC], > @@ -599,14 +607,6 @@ > model.setValue(iter, (DataColumnString) cols[2], ins.instruction); > model.setValue(iter, (DataColumnObject) cols[3], ins); > > - if (li.hasNext()) > - ins = (Instruction) li.next(); > - else > - { > - this.toSpin.setValue((double) ins.address); > - this.lastKnownTo = ins.address; > - ins = null; > - } > } > else > model.setValue(iter, (DataColumnString) cols[1], ""); > @@ -679,9 +679,10 @@ > } > } > > - refreshList(); > + this.fromSpin.setValue(val); > this.lastKnownFrom = val; > this.fromBox.setText(Long.toHexString((long) val)); > + refreshList(); > } > > boolean toToggle = false; > diff -ur frysk-cvs/frysk-gui/frysk/gui/memory/MemoryWindow.java frysk/frysk-gui/frysk/gui/memory/MemoryWindow.java > --- frysk-cvs/frysk-gui/frysk/gui/memory/MemoryWindow.java 2007-07-26 10:11:33.000000000 -0400 > +++ frysk/frysk-gui/frysk/gui/memory/MemoryWindow.java 2007-07-26 10:14:45.000000000 -0400 > @@ -475,12 +475,12 @@ > { > public void entryEvent (EntryEvent arg0) > { > - if (arg0.getType() == EntryEvent.Type.CHANGED) > + if (arg0.getType() == EntryEvent.Type.ACTIVATE) > { > if (refreshLock) > return; > > - String str = arg0.getText(); > + String str = fromBox.getText(); > try > { > double d = (double) Long.parseLong(str, 16); > @@ -499,12 +499,12 @@ > { > public void entryEvent (EntryEvent arg0) > { > - if (arg0.getType() == EntryEvent.Type.CHANGED) > + if (arg0.getType() == EntryEvent.Type.ACTIVATE) > { > if (refreshLock) > return; > > - String str = arg0.getText(); > + String str = toBox.getText(); > try > { > double d = (double) Long.parseLong(str, 16); > @@ -874,7 +874,7 @@ > { > TreeIter iter = model.getFirstIter(); > > - for (int i = (int) lastKnownFrom; i < (int) val; i++) > + for (long i = (long) lastKnownFrom; i < (long) val; i++) > { > model.removeRow(iter); > iter = iter.getNextIter(); > @@ -931,6 +931,7 @@ > } > > this.toBox.setText(Long.toHexString((long) val)); > + this.toSpin.setValue(val); > refreshList(); > } > > From kris.van.hees@oracle.com Mon Jul 30 14:39:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Mon, 30 Jul 2007 14:39:00 -0000 Subject: [patch] fix bug 4612 In-Reply-To: <46ADE15B.20505@redhat.com> References: <1185502689.4051.15.camel@linux-pzhao.site> <46ADE15B.20505@redhat.com> Message-ID: <20070730143927.GA22305@oracle.com> The code duplication between the Disassembler and Memory windows has been mentioned during the conf call where I pointed out the various problems found with those windows (and their implementation). It certainly could do with a refactoring, although it is too early for that right now. For one, I do not think it is wise to do it as part of a bug fix, and secondly, the planned changes to the Memory window will cause it to deviate more from the Disassembler window than it does now, so premature refactoring is likely to need a (partial) reversal later on. Cheers, Kris On Mon, Jul 30, 2007 at 09:02:19AM -0400, Andrew Cagney wrote: > Pearly, > > The below looks fine. Will you be around tuesday morning (your time?). > I'll send you off list some stuff to do with CVS so that you can check this > in. > > Two things to think about though: > > -> testing; > When making fixes we all endeavor to author the test-case up-front so that > we can directly demonstrate that the change has the intended effect. > > -> it looks like there is much code duplication between the Disassembler > and Memory windows; > an opportunity to refactor? From kris.van.hees@oracle.com Mon Jul 30 15:10:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Mon, 30 Jul 2007 15:10:00 -0000 Subject: [patch] fix bug 4612 In-Reply-To: <20070730143927.GA22305@oracle.com> References: <1185502689.4051.15.camel@linux-pzhao.site> <46ADE15B.20505@redhat.com> <20070730143927.GA22305@oracle.com> Message-ID: <20070730150949.GB22305@oracle.com> Woops, my apologies for sending this off before responding to the first point as well (I guess I do need more coffee): I do agree that testing is important (obviously), and hope that we will be able to increase our GUI test coverage as time goes by. However, it clearly has been a problem in the past as well (as witnessed by the very limited amount of GUI tests that currently exist), and that is very understandable given the framework needed to create those tests. Andrew even mentioned at OLS thatthe GUI is essentially not tested. But we do need to get these bugs fixed, and make the GUI usable. Given the complexity writing GUI tests (using dogtail), it seem more prudent to wait for the affected windows to stabilize to write tests. Otherwise it's just going to be a wasted effort. Cheers, Kris On Mon, Jul 30, 2007 at 10:39:27AM -0400, Kris Van Hees wrote: > The code duplication between the Disassembler and Memory windows has been > mentioned during the conf call where I pointed out the various problems > found with those windows (and their implementation). It certainly could do > with a refactoring, although it is too early for that right now. For one, > I do not think it is wise to do it as part of a bug fix, and secondly, the > planned changes to the Memory window will cause it to deviate more from the > Disassembler window than it does now, so premature refactoring is likely to > need a (partial) reversal later on. > > Cheers, > Kris > > On Mon, Jul 30, 2007 at 09:02:19AM -0400, Andrew Cagney wrote: > > Pearly, > > > > The below looks fine. Will you be around tuesday morning (your time?). > > I'll send you off list some stuff to do with CVS so that you can check this > > in. > > > > Two things to think about though: > > > > -> testing; > > When making fixes we all endeavor to author the test-case up-front so that > > we can directly demonstrate that the change has the intended effect. > > > > -> it looks like there is much code duplication between the Disassembler > > and Memory windows; > > an opportunity to refactor? From cagney@redhat.com Mon Jul 30 15:18:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 30 Jul 2007 15:18:00 -0000 Subject: [patch] fix bug 4612 In-Reply-To: <20070730143927.GA22305@oracle.com> References: <1185502689.4051.15.camel@linux-pzhao.site> <46ADE15B.20505@redhat.com> <20070730143927.GA22305@oracle.com> Message-ID: <46AE011D.5020605@redhat.com> Kris, Our guideline is: re-factor early, re-factor often(1). Here we trust and allow Pearly to make a decision such as when to best apply a refactorings. Andrew (1) A refactoring , by definition, is not part of a functional change such as a bug fix. Kris Van Hees wrote: > The code duplication between the Disassembler and Memory windows has been > mentioned during the conf call where I pointed out the various problems > found with those windows (and their implementation). It certainly could do > with a refactoring, although it is too early for that right now. For one, > I do not think it is wise to do it as part of a bug fix, and secondly, the > planned changes to the Memory window will cause it to deviate more from the > Disassembler window than it does now, so premature refactoring is likely to > need a (partial) reversal later on. > > Cheers, > Kris > > On Mon, Jul 30, 2007 at 09:02:19AM -0400, Andrew Cagney wrote: > >> Pearly, >> >> The below looks fine. Will you be around tuesday morning (your time?). >> I'll send you off list some stuff to do with CVS so that you can check this >> in. >> >> Two things to think about though: >> >> -> testing; >> When making fixes we all endeavor to author the test-case up-front so that >> we can directly demonstrate that the change has the intended effect. >> >> -> it looks like there is much code duplication between the Disassembler >> and Memory windows; >> an opportunity to refactor? >> From cagney@redhat.com Mon Jul 30 15:38:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 30 Jul 2007 15:38:00 -0000 Subject: [patch] fix bug 4612 In-Reply-To: <20070730150949.GB22305@oracle.com> References: <1185502689.4051.15.camel@linux-pzhao.site> <46ADE15B.20505@redhat.com> <20070730143927.GA22305@oracle.com> <20070730150949.GB22305@oracle.com> Message-ID: <46AE05F6.8050203@redhat.com> Kris, Yes, the dogtail testing. You'll see that there frysk-gui tree now also contains JUnit tests; and we're able to more directly test components using that. Pearly, you may want to talk to Sami about opportunities here. Andrew Kris Van Hees wrote: > Woops, my apologies for sending this off before responding to the first point > as well (I guess I do need more coffee): > > I do agree that testing is important (obviously), and hope that we will be able > to increase our GUI test coverage as time goes by. However, it clearly has > been a problem in the past as well (as witnessed by the very limited amount of > GUI tests that currently exist), and that is very understandable given the > framework needed to create those tests. Andrew even mentioned at OLS thatthe > GUI is essentially not tested. > > But we do need to get these bugs fixed, and make the GUI usable. Given the > complexity writing GUI tests (using dogtail), it seem more prudent to wait for > the affected windows to stabilize to write tests. Otherwise it's just going > to be a wasted effort. > > Cheers, > Kris > > On Mon, Jul 30, 2007 at 10:39:27AM -0400, Kris Van Hees wrote: > >> The code duplication between the Disassembler and Memory windows has been >> mentioned during the conf call where I pointed out the various problems >> found with those windows (and their implementation). It certainly could do >> with a refactoring, although it is too early for that right now. For one, >> I do not think it is wise to do it as part of a bug fix, and secondly, the >> planned changes to the Memory window will cause it to deviate more from the >> Disassembler window than it does now, so premature refactoring is likely to >> need a (partial) reversal later on. >> >> Cheers, >> Kris >> >> On Mon, Jul 30, 2007 at 09:02:19AM -0400, Andrew Cagney wrote: >> >>> Pearly, >>> >>> The below looks fine. Will you be around tuesday morning (your time?). >>> I'll send you off list some stuff to do with CVS so that you can check this >>> in. >>> >>> Two things to think about though: >>> >>> -> testing; >>> When making fixes we all endeavor to author the test-case up-front so that >>> we can directly demonstrate that the change has the intended effect. >>> >>> -> it looks like there is much code duplication between the Disassembler >>> and Memory windows; >>> an opportunity to refactor? >>> From cagney@redhat.com Mon Jul 30 15:47:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 30 Jul 2007 15:47:00 -0000 Subject: Testing frysk.testbed.Funit* Message-ID: <46AE081A.8070503@redhat.com> Hi, I'm looking at ways to more directly test the frysk.testbed.Funit* classes (e.g., FunitExec, DetachedAckProcess) that wrap PKGLIBDIR/funit-* utilities, but am finding that the most effective route is to use frysk.proc's framework - duplicating the existing frysk.proc tests exercising frysk.proc functionality that is effectively testing that code. I could duplicate the tests but it seems redundant. Any thoughts on a strategy? Andrew From swagiaal@redhat.com Mon Jul 30 15:48:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Mon, 30 Jul 2007 15:48:00 -0000 Subject: [patch] fix bug 4612 In-Reply-To: <46AE05F6.8050203@redhat.com> References: <1185502689.4051.15.camel@linux-pzhao.site> <46ADE15B.20505@redhat.com> <20070730143927.GA22305@oracle.com> <20070730150949.GB22305@oracle.com> <46AE05F6.8050203@redhat.com> Message-ID: <46AE0821.6060909@redhat.com> Andrew Cagney wrote: > Kris, > > Yes, the dogtail testing. You'll see that there frysk-gui tree now > also contains JUnit tests; and we're able to more directly test > components using that. > > Pearly, you may want to talk to Sami about opportunities here. Data structures, and objects that the gui relies on, such as Observers, Sessions are tested through junit. This is the thin layer under the gui and ontop of the core. So you might not be able to test that a button does what it should do, but the code it relies on is junit testable. Sami From swagiaal@redhat.com Mon Jul 30 16:20:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Mon, 30 Jul 2007 16:20:00 -0000 Subject: [patch] fix bug 4612 In-Reply-To: <46AE05F6.8050203@redhat.com> References: <1185502689.4051.15.camel@linux-pzhao.site> <46ADE15B.20505@redhat.com> <20070730143927.GA22305@oracle.com> <20070730150949.GB22305@oracle.com> <46AE05F6.8050203@redhat.com> Message-ID: <46AE0FC1.3090004@redhat.com> Andrew Cagney wrote: > Kris, > > Yes, the dogtail testing. You'll see that there frysk-gui tree now > also contains JUnit tests; and we're able to more directly test > components using that. > > Pearly, you may want to talk to Sami about opportunities here. By the way phil is a good reference too, he wrote more than half of those tests and is intimately familiar with the gui code. From mark@klomp.org Mon Jul 30 16:53:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 30 Jul 2007 16:53:00 -0000 Subject: Make CoredumpAction use Task.getRegisterBanks() Message-ID: <1185814384.3674.36.camel@dijkstra.wildebeest.org> Hi, Phil and me were discussing cleaning up some of the Memory/RegisterBuffers between ptrace and core proc Tasks on irc and noticed that CoredumpAction was accessing the RegisterBanks directly through the Isa. To make splitting the issue of getting the RegisterBanks (Task specific) and doing the Register name mapping to bank number and offset (Isa specific) easier we wanted to make all code go through Task.getRegisterBanks(). This patch does that for CoredumpAction: 2007-07-30 Mark Wielaard * CoredumpAction.java (): Use Task.getRegisterBanks() not Isa.getRegisterBankBuffers(). Tested on x86 and x86_64 without regressions. Cheers, Mark diff -u -r1.16 CoredumpAction.java --- frysk-core/frysk/util/CoredumpAction.java 16 Jul 2007 22:11:35 -0000 1.16 +++ frysk-core/frysk/util/CoredumpAction.java 30 Jul 2007 16:40:07 -0000 @@ -235,11 +235,8 @@ { // New PRSTATUS Note Entry. ElfPrFPRegSet fpRegSet = new ElfPrFPRegSet(); - Isa register = null; - - register = task.getIsa(); - ByteBuffer registerMaps[] = register.getRegisterBankBuffers(task.getProc().getPid()); + ByteBuffer registerMaps[] = task.getRegisterBanks(); if (registerMaps[1].capacity() <= 0) abandonCoreDump(new RuntimeException("FP Register bank is <=0")); byte[] regBuffer = new byte[(int) registerMaps[1].capacity()]; -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From elena.zannoni@oracle.com Mon Jul 30 17:26:00 2007 From: elena.zannoni@oracle.com (Elena Zannoni) Date: Mon, 30 Jul 2007 17:26:00 -0000 Subject: [patch] fix bug 4612 In-Reply-To: <46ADE15B.20505@redhat.com> References: <1185502689.4051.15.camel@linux-pzhao.site> <46ADE15B.20505@redhat.com> Message-ID: <46AE1F30.2000904@oracle.com> To clarify: This patch was discussed on IRC and Mark and other folks have provided useful feedback and testing. The patch had also been tested by Kris before being posted by Pearly. Kris has already committed Pearly's patch, since nobody but him and Pearly are concentrating on that part of GUI right now. An ack to the mailing list could have been sent, since discussing things on IRC exclusively is not really optimal practice for a fully open source project. I'd like to take the opportunity to appeal to the wider group to be more consistent in doing so. Kris committing this patch has aroused an unfortunate not so friendly private reaction, which I will not post here. What I'd like to bring up here though is about approval of patches. It is my personal belief for it to be good practice to not be anointed with write access just because one happens to be tasked to work on the project. I have asked Pearly to submit a few patches before applying for write access to the repository. Since the group has been widening, and hopefully it will widen more as Frysk matures nicely, there are cases in which people w/o commit rights will want to post patches occasionally (we have seen this already with Tom or others). So far people who felt comfortable taking responsibility for such patches have committed them. I do believe this is a good way to incorporate contributions from outside the committers list. From pmuldoon@redhat.com Mon Jul 30 17:44:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Mon, 30 Jul 2007 17:44:00 -0000 Subject: Make CoredumpAction use Task.getRegisterBanks() In-Reply-To: <1185814384.3674.36.camel@dijkstra.wildebeest.org> References: <1185814384.3674.36.camel@dijkstra.wildebeest.org> Message-ID: <46AE238B.5020204@redhat.com> Mark Wielaard wrote: > Hi, > > Phil and me were discussing cleaning up some of the > Memory/RegisterBuffers between ptrace and core proc Tasks on irc and > noticed that CoredumpAction was accessing the RegisterBanks directly > through the Isa. To make splitting the issue of getting the > RegisterBanks (Task specific) and doing the Register name mapping to > bank number and offset (Isa specific) easier we wanted to make all code > go through Task.getRegisterBanks(). This patch does that for > CoredumpAction: > Looks good. The only function here is to attain the raw memory behind the byte buffers for floating point registers, as that is dumped whole into the FP Register Note. CoredumpAction has been gutted locally and being refactored into a Corefile{arch}factory. I'll take your patch and reconstitute it there Many Thanks Phil From npremji@redhat.com Mon Jul 30 19:53:00 2007 From: npremji@redhat.com (Nurdin Premji) Date: Mon, 30 Jul 2007 19:53:00 -0000 Subject: Regs command Message-ID: <46AE41AD.601@redhat.com> I've just added a regs command to the fhpd to display registers. Currently only works with general registers. You can run: (fhpd) regs which will print out the general registers, or (fhpd) regs REGISTER_GROUP which will attempt to print the given register group (currently if it isn't general it will crash). From scox@redhat.com Mon Jul 30 20:41:00 2007 From: scox@redhat.com (Stan Cox) Date: Mon, 30 Jul 2007 20:41:00 -0000 Subject: dereferencing pointers from frysk.value In-Reply-To: <46AA1512.3040908@redhat.com> References: <1185548524.11775.27.camel@multics.rdu.redhat.com> <46AA1512.3040908@redhat.com> Message-ID: <1185828018.11775.71.camel@multics.rdu.redhat.com> On Fri, 2007-07-27 at 11:53 -0400, Andrew Cagney wrote: > So at present a "pointer" value is seen as a pair: > type: pointer->char > location: byte-buffer with size==sizeof(void*) and > contents=="pointer value" > and there's nothing for the "pointer" to point into? Right. Pointer operators are special cased so pointer class members were the primary culprits. Good idea to parameterize printing with the buffer. Now char* pointers get expanded similar to gdb (the formatting is a little rough around the edges): (fhpd) what mb extern Type at (fhpd) what Type (inherits from Base1 and Base2) {{byte * msg;void Base1 (byte * ) ;void ~Base1 () ;} Base1;{byte * msg;void Base2 (byte * ) ;void ~Base2 () ;} Base2;byte * note;void Type (byte * ,byte * ,byte * ) ;void ~Type () ;} at /home/scox/accu/src/tstctors0.cc#33 (fhpd) print mb {Base1={msg=0x401240 "static",Base1,~Base1},Base2={msg=0x40123b "main",Base2,~Base2},note=0x401238 "mb",Type,~Type} By the way here is an early template example (very rough formatting): (fhpd) what xyz Derived at /home/scox/accu/src/tstctors0.cc#79 (fhpd) what Derived {{void * * _vptr.Base3;void Base3 () ;void Base3 () ;char do_this (char ) ;short int do_this (short int ) ;int do_this (int ) ;float do_this (float ) ;} Base3;void Derived () ;void Derived () ;char do_this (char ) ;short int do_this (short int ) ;int do_this (int ) ;float do_this (float ) ;char do_this_impl (char ) ;short int do_this_impl (short int ) ;int do_this_impl (int ) ;float do_this_impl (float ) ;} at /home/scox/accu/src/tstctors0.cc#57 (fhpd) print xyz void* {Base3={_vptr.Base3=0x401290,Base3,Base3,do_this,do_this,do_this,do_this},Derived,Derived,do_this,do_this,do_this,do_this,do_this_impl,do_this_impl,do_this_impl,do_this_impl} From pmuldoon@redhat.com Tue Jul 31 00:02:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 31 Jul 2007 00:02:00 -0000 Subject: frysk-core/frysk stack/Frame.java stack/Change ... In-Reply-To: <20070730195006.8817.qmail@sourceware.org> References: <20070730195006.8817.qmail@sourceware.org> Message-ID: <46AE7BF2.1020603@redhat.com> npremji@sourceware.org wrote: > frysk/proc/CL > * IsaIA32.java (regDefs): Expanded "efl" to "eflags". > Just as a note, this broke CoredumpAction (and TestFCore tests) which continued to use efl instead of eflags. I'll fix it in the refactored version, but there could be other cases elsewhere relying on the name efl over eflags. Might be worth investigation Regards Phil From scox@redhat.com Tue Jul 31 01:45:00 2007 From: scox@redhat.com (Stan Cox) Date: Tue, 31 Jul 2007 01:45:00 -0000 Subject: Regs command In-Reply-To: <46AE41AD.601@redhat.com> References: <46AE41AD.601@redhat.com> Message-ID: <1185846259.9874.18.camel@multics.rdu.redhat.com> Nice. Could we also have hex output as with gdb's "info registers"? Is there an fhpd request "regs"? If not would "registers" be a more descriptive name? From kris.van.hees@oracle.com Tue Jul 31 02:13:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Tue, 31 Jul 2007 02:13:00 -0000 Subject: TestLeakingFileDescriptor Message-ID: <20070731021143.GD22305@oracle.com> I'd like to propose that the TestLeakingFileDescriptor test cases be marked as stress tests rather than regular tests, to avoid them being executed at every testsuite invocation. Reason for this proposal is two-fold: first of all, these tests are implicitly intermittent due to the fact that they depend on a behaviour that is not deterministic (the garbage collector does not actually do I/O resource mangement), and secondly, when they do fail they tend to cause a bunch of side effects (causing later tests to fail, causing daemon instances of TestRunner to never get torn down, ...). Cheers, Kris From mark@klomp.org Tue Jul 31 09:57:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 31 Jul 2007 09:57:00 -0000 Subject: Problem with getExe and testInsertedBreakpoint In-Reply-To: <20070727190347.504344D058D@magilla.localdomain> References: <20070727190347.504344D058D@magilla.localdomain> Message-ID: <1185875847.3653.60.camel@dijkstra.wildebeest.org> Hi Roland, On Fri, 2007-07-27 at 12:03 -0700, Roland McGrath wrote: > > Will it be possible for frysk to also support that in the Fedora 8 > > timeframe? > > I intend to have some libdwfl additions for build-id before F8. > Those will make it very easy to do something in Frysk. That would make it easy to fixup the core file consumer part in frysk indeed. But we would still need to make sure that when we produce core files we also include the BuildID. > > OK, and I assume the same would be true for any code segments that were > > altered through ptrace poke? > > Correct. The kernel's test is on its internal VM data structures, so it > gets any private file mapping that has had some COW happen. Nice to know. Somewhat related, is there some way to revert this? In the case of inserting low-level breakpoints all we really do is setting one instruction and then later resetting the original instruction. Is there any way to make the kernel know that the page can be remerged again because all writes to it have been reversed? Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Tue Jul 31 10:03:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 31 Jul 2007 10:03:00 -0000 Subject: Testing frysk.testbed.Funit* In-Reply-To: <46AE081A.8070503@redhat.com> References: <46AE081A.8070503@redhat.com> Message-ID: <1185876171.3653.64.camel@dijkstra.wildebeest.org> Hi Andrew, On Mon, 2007-07-30 at 11:47 -0400, Andrew Cagney wrote: > I'm looking at ways to more directly test the frysk.testbed.Funit* > classes (e.g., FunitExec, DetachedAckProcess) that wrap > PKGLIBDIR/funit-* utilities, but am finding that the most effective > route is to use frysk.proc's framework - duplicating the existing > frysk.proc tests exercising frysk.proc functionality that is effectively > testing that code. > > I could duplicate the tests but it seems redundant. Any thoughts on a > strategy? I might be missing the exact cases you want to test. But can't you just audit the current frysk.proc tests to see if they cover all relevant cases already and if not add one or two tests to the existing proc tests so all cases are covered? That way you will also extend the real proc tests to handle more cases catching two birds with one stone (if that isn't a terribly political incorrect saying). Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From roland@redhat.com Tue Jul 31 10:18:00 2007 From: roland@redhat.com (Roland McGrath) Date: Tue, 31 Jul 2007 10:18:00 -0000 Subject: Problem with getExe and testInsertedBreakpoint In-Reply-To: Mark Wielaard's message of Tuesday, 31 July 2007 11:57:27 +0200 <1185875847.3653.60.camel@dijkstra.wildebeest.org> Message-ID: <20070731101817.109AB4D04BA@magilla.localdomain> > But we would still need to make sure that when we produce core files we > also include the BuildID. What the changed kernel does is easy to replicate. When you otherwise would have elided a segment and it's a private mapping (...p in 2nd column of /proc/pid/maps) at offset 0 (3rd column), check if its contents begin with "\177ELF". If so, don't elide the first page of that segment. > Is there any way to make the kernel know that the page can > be remerged again because all writes to it have been reversed? No. This is one of the benefits that would come from the "fancy VM tricks" future item (don't bother asking for details, there aren't any). Thanks, Roland From mark@klomp.org Tue Jul 31 10:24:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 31 Jul 2007 10:24:00 -0000 Subject: [patch] fix bug 4612 In-Reply-To: <46AE1F30.2000904@oracle.com> References: <1185502689.4051.15.camel@linux-pzhao.site> <46ADE15B.20505@redhat.com> <46AE1F30.2000904@oracle.com> Message-ID: <1185877433.3653.70.camel@dijkstra.wildebeest.org> Hi Elena, On Mon, 2007-07-30 at 13:26 -0400, Elena Zannoni wrote: > To clarify: > This patch was discussed on IRC and Mark and other folks have provided > useful feedback and testing. The patch had also been tested by Kris before > being posted by Pearly. Kris has already committed Pearly's patch, > since nobody but him and Pearly are concentrating on that part > of GUI right now. > > An ack to the mailing list could have been sent, since discussing things > on IRC exclusively is not really optimal practice for a fully open > source project. I'd like to take the opportunity to appeal to the > wider group to be more consistent in doing so. That seems like a good policy. I will also try to summarize and post more about anything on the list that was discussed on irc to keep an archive of stuff for people to look at. We seem pretty scattered around according to timezones over the whole planet so there is always someone missing out on some discussion somewhere. > Kris committing this patch has aroused an unfortunate not so friendly > private reaction, which I will not post here. What I'd like to bring up here > though is about approval of patches. It is my personal belief for it to > be good practice to not be anointed with write access just because one > happens to be tasked to work on the project. I have asked Pearly to submit > a few patches before applying for write access to the repository. Since > the group has been widening, and hopefully it will widen more as > Frysk matures nicely, there are cases in which people w/o commit rights > will want to post patches occasionally (we have seen this already with > Tom or others). So far people who felt comfortable taking responsibility > for such patches have committed them. I do believe this is a good way > to incorporate contributions from outside the committers list. Yes, I am more than happy to take responsibility for reviewing and committing peoples patches if they ask. In this case I thought the patch was good but wanted to have a second opinion from Rick and Kris before committing because they are much more familiar with gui code than me. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Tue Jul 31 10:50:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 31 Jul 2007 10:50:00 -0000 Subject: [patch] IA32 subsyscall list fixes Message-ID: <1185879001.3653.75.camel@dijkstra.wildebeest.org> Hi, Rick found an off by one error in the IA32 IPC subsyscall list, we forgot to skip subcall zero. This patch fixes that and adds an extra sanity/robustness check in case someone tries to make a socket or ipc subsyscall with an unknown number. 2007-07-31 Mark Wielaard Fixes bug #4865 * LinuxIa32Syscall.java (unknownIpcSubSyscall): New static field. (unknownSocketSubSyscall): Likewise. (ipcSubcallList): Add unknown numbers, including zero. (syscallByNum): Bounds check socketSubcallList and ipcSubcallList arrays before returning possible unknown subsyscall. This makes it possible to ftrace FryskGui which is a nice stress tests. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: LinuxIa32Syscall.patch Type: text/x-patch Size: 3234 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Tue Jul 31 11:00:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 31 Jul 2007 11:00:00 -0000 Subject: TestLeakingFileDescriptor In-Reply-To: <20070731021143.GD22305@oracle.com> References: <20070731021143.GD22305@oracle.com> Message-ID: <1185879622.3653.80.camel@dijkstra.wildebeest.org> Hi Kris, On Mon, 2007-07-30 at 22:11 -0400, Kris Van Hees wrote: > I'd like to propose that the TestLeakingFileDescriptor test cases be marked > as stress tests rather than regular tests, to avoid them being executed at > every testsuite invocation. Reason for this proposal is two-fold: first of > all, these tests are implicitly intermittent due to the fact that they depend > on a behaviour that is not deterministic (the garbage collector does not > actually do I/O resource mangement), and secondly, when they do fail they tend > to cause a bunch of side effects (causing later tests to fail, causing daemon > instances of TestRunner to never get torn down, ...). I think that is a good idea since the test results are pretty flaky as they are now making comparing test runs pretty hard. I known good set of tests that always PASS and that you don't have to second guess would be really helpful. Only issue I can see is that if the stress tests are optional people will never run them, but I guess that is what the autobuilder/tester is for. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Tue Jul 31 11:25:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 31 Jul 2007 11:25:00 -0000 Subject: frysk-core/frysk stack/Frame.java stack/Change ... In-Reply-To: <46AE7BF2.1020603@redhat.com> References: <20070730195006.8817.qmail@sourceware.org> <46AE7BF2.1020603@redhat.com> Message-ID: <1185881092.3653.87.camel@dijkstra.wildebeest.org> On Mon, 2007-07-30 at 19:01 -0500, Phil Muldoon wrote: > npremji@sourceware.org wrote: > > frysk/proc/CL > > * IsaIA32.java (regDefs): Expanded "efl" to "eflags". > > > > Just as a note, this broke CoredumpAction (and TestFCore tests) which > continued to use efl instead of eflags. I'll fix it in the refactored > version, but there could be other cases elsewhere relying on the name > efl over eflags. Might be worth investigation A quick scan didn't show any other uses of the old name. x86_64 already used the eflags name. To get closer to zero fail again on x86 I committed the trivial fix, and removed some left over debug output in the code. 2007-07-31 Mark Wielaard * StacktraceAction.java (printTasks): Remove debug println. * CoredumpAction.java (fillENotePrstatus): Rename elf to elflags. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: elflags.patch Type: text/x-patch Size: 2084 bytes Desc: not available URL: From mark@klomp.org Tue Jul 31 12:03:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 31 Jul 2007 12:03:00 -0000 Subject: Make CoredumpAction use Task.getRegisterBanks() In-Reply-To: <46AE238B.5020204@redhat.com> References: <1185814384.3674.36.camel@dijkstra.wildebeest.org> <46AE238B.5020204@redhat.com> Message-ID: <1185883408.3653.106.camel@dijkstra.wildebeest.org> Hi Phil, On Mon, 2007-07-30 at 12:44 -0500, Phil Muldoon wrote: > Mark Wielaard wrote: > > Phil and me were discussing cleaning up some of the > > Memory/RegisterBuffers between ptrace and core proc Tasks on irc and > > noticed that CoredumpAction was accessing the RegisterBanks directly > > through the Isa. To make splitting the issue of getting the > > RegisterBanks (Task specific) and doing the Register name mapping to > > bank number and offset (Isa specific) easier we wanted to make all code > > go through Task.getRegisterBanks(). This patch does that for > > CoredumpAction: > > > Looks good. The only function here is to attain the raw memory behind > the byte buffers for floating point registers, as that is dumped whole > into the FP Register Note. > > CoredumpAction has been gutted locally and being refactored into a > Corefile{arch}factory. I'll take your patch and reconstitute it there Thanks. Please let me know if I should hold off on the rest of the register banks cleanup till you finished this. Or if you want me to take a look at what you have now to get a better understanding how to clean up these buffers. For ptrace/proc based Tasks there are basically 4 register banks (not all of them used on all architectures) the Isa provides a mapping from the actual register names to the bank and offset inside it. The four banks are the regular registers (gotten through PTRACE_GETREGS), the general floating point registers (gotten through PTRACE_GETFPREGS), the extended floating point registers such like sse xmm registers (gotten through PTRACE_getXFPREGS) and the other registers (gotten through the start of USR memory space) that cover things like debug control registers found by the Isa through the mapping in sys/user.h (some of the other register banks are actually also contained in this one). Does this map somewhat to how core files handle the register banks, so you can just dump/read these banks from them? Cheers, Mark From cagney@redhat.com Tue Jul 31 13:35:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 31 Jul 2007 13:35:00 -0000 Subject: TestLeakingFileDescriptor In-Reply-To: <20070731021143.GD22305@oracle.com> References: <20070731021143.GD22305@oracle.com> Message-ID: <46AF3AB5.7030703@redhat.com> It is very hard to comment on a technical when the technical background is limited. Can you please provide an example of the problem, perhaps reduced to an automated test-case? As they say, they pass for me. Is your testbed the motivation behind this request? We can certainly explore options such as moving some of the tests to the stress test-suite; however the quid-pro-quo is that we have also analyzed failing cases identified by the stress test and added deterministic fixes for them. Andrew Kris Van Hees wrote: > I'd like to propose that the TestLeakingFileDescriptor test cases be marked > as stress tests rather than regular tests, to avoid them being executed at > every testsuite invocation. Reason for this proposal is two-fold: first of > all, these tests are implicitly intermittent due to the fact that they depend > on a behaviour that is not deterministic (the garbage collector does not > actually do I/O resource mangement), and secondly, when they do fail they tend > to cause a bunch of side effects (causing later tests to fail, causing daemon > instances of TestRunner to never get torn down, ...). > > Cheers, > Kris > From cagney@redhat.com Tue Jul 31 13:48:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 31 Jul 2007 13:48:00 -0000 Subject: frysk meeting 2007-08-01 Message-ID: <46AF3DBE.1020802@redhat.com> All welcome, please contact me off list for dial in information. This week; walking through one or more off: -> fstack -> disassembler (again :-) -> fdebuginfo From cagney@redhat.com Tue Jul 31 15:30:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 31 Jul 2007 15:30:00 -0000 Subject: [patch] IA32 subsyscall list fixes In-Reply-To: <1185879001.3653.75.camel@dijkstra.wildebeest.org> References: <1185879001.3653.75.camel@dijkstra.wildebeest.org> Message-ID: <46AF55A9.5060902@redhat.com> Mark, You mentioned an off-by-one error in the syscall code. Is that now being tested? Andrew From cagney@redhat.com Tue Jul 31 15:57:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 31 Jul 2007 15:57:00 -0000 Subject: Testing frysk.testbed.Funit* In-Reply-To: <1185876171.3653.64.camel@dijkstra.wildebeest.org> References: <46AE081A.8070503@redhat.com> <1185876171.3653.64.camel@dijkstra.wildebeest.org> Message-ID: <46AF5BDE.6000806@redhat.com> Mark Wielaard wrote: > Hi Andrew, > > On Mon, 2007-07-30 at 11:47 -0400, Andrew Cagney wrote: > >> I'm looking at ways to more directly test the frysk.testbed.Funit* >> classes (e.g., FunitExec, DetachedAckProcess) that wrap >> PKGLIBDIR/funit-* utilities, but am finding that the most effective >> route is to use frysk.proc's framework - duplicating the existing >> frysk.proc tests exercising frysk.proc functionality that is effectively >> testing that code. >> >> I could duplicate the tests but it seems redundant. Any thoughts on a >> strategy? >> > > Mark, you describe the current state of play; frysk.proc code is testing both itself internally and the funit tools implicitly. There's nothing directly testing units such as FunitExecOffspring; instead it is done implicitly via frysk.proc. That is great when it works, but not so great when tests fail as differentiating between an FunitExecOffspring or frysk.proc breakage that caused the fail isn't possible. As a contrasting example. Say we find the UI is crashing and track it down to a dwarf binding bug. What we do is add a test-case to the dwarf bindings testing the problem (which contains the root cause of the problem); and then fix it. Is the core code is now being tested, we're confident that our problem won't return. Is there an effective way to do that here with the Funit* bindings? Andrew > I might be missing the exact cases you want to test. But can't you just > audit the current frysk.proc tests to see if they cover all relevant > cases already and if not add one or two tests to the existing proc tests > so all cases are covered? That way you will also extend the real proc > tests to handle more cases catching two birds with one stone (if that > isn't a terribly political incorrect saying). > > Cheers, > > Mark > From cagney@redhat.com Tue Jul 31 18:15:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 31 Jul 2007 18:15:00 -0000 Subject: frysk meeting 2007-08-01 In-Reply-To: <46AF3DBE.1020802@redhat.com> References: <46AF3DBE.1020802@redhat.com> Message-ID: <46AF7C3A.90509@redhat.com> + discuss switching to git and/or mercurial Andrew Cagney wrote: > All welcome, please contact me off list for dial in information. > > This week; walking through one or more off: > -> fstack > -> disassembler (again :-) > -> fdebuginfo > From swagiaal@redhat.com Tue Jul 31 18:42:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Tue, 31 Jul 2007 18:42:00 -0000 Subject: frysk-core/frysk stack/Frame.java stack/Change ... In-Reply-To: <20070730195006.8817.qmail@sourceware.org> References: <20070730195006.8817.qmail@sourceware.org> Message-ID: <46AF82A4.5040900@redhat.com> Nurdin, > frysk/stack/CL > * Frame.java (getRegisterValue): Added. [...] > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/stack/Frame.java.diff?cvsroot=frysk&r1=1.10&r2=1.11 > Does/should this replace getRigerster(int reg) ? From npremji@redhat.com Tue Jul 31 18:42:00 2007 From: npremji@redhat.com (Nurdin Premji) Date: Tue, 31 Jul 2007 18:42:00 -0000 Subject: fhpd: HpdCommandParser added. Message-ID: <46AF8295.30105@redhat.com> I've added an fhpd command option parser that is heavily based on the getopt option parser, (but the help option will not exit the fhpd) The only assumption made by this parser is that options are located at the end of the command. There is also the ability to add a '--' and anything preceding that is considered to be part of the command arguments. So: command --variable will assume 'variable' is an option, whereas command --variable -- will assume '--variable' is a command argument. Currently the disassemble command is the only one to use this parser, but it should be easy to switch other commands over, CLIHandler has a parser added into it. From npremji@redhat.com Tue Jul 31 18:46:00 2007 From: npremji@redhat.com (Nurdin Premji) Date: Tue, 31 Jul 2007 18:46:00 -0000 Subject: frysk-core/frysk stack/Frame.java stack/Change ... In-Reply-To: <46AF82A4.5040900@redhat.com> References: <20070730195006.8817.qmail@sourceware.org> <46AF82A4.5040900@redhat.com> Message-ID: <46AF837C.1030205@redhat.com> Sami Wagiaalla wrote: > Nurdin, >> frysk/stack/CL >> * Frame.java (getRegisterValue): Added. > [...] > >> http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/stack/Frame.java.diff?cvsroot=frysk&r1=1.10&r2=1.11 >> >> > Does/should this replace getRigerster(int reg) ? > Yup, it will soon. From tthomas@redhat.com Tue Jul 31 21:59:00 2007 From: tthomas@redhat.com (Teresa Thomas) Date: Tue, 31 Jul 2007 21:59:00 -0000 Subject: Debuginfo utilities added Message-ID: <46AFB0B7.1040806@redhat.com> I have just merged my branch with the main branch and committed the changes. As mentioned earlier, I've added two new related utilities in frysk/frysk-core/bindir: 1) fdebuginfo - which lists the debuginfo paths for the (attached) process' modules. Its output format is a simple list of module names, followed by their debuginfo paths. Paths for ones that do not contain debuginfo, are shown as "---". 2) fdebugrpm - which is a bash script that allows you to install the missing debuginfo packages using yum. This lists the missing debuginfo packages, and gives the user a choice to install them. fdebugrpm internally runs fdebuginfo to obtain the names of the modules that are missing debugging information. For now, I suggest running fdebugrpm through the install tree (rather than the build tree) as the scripts direct it to look for fdebuginfo in this directory. This allows the scripts to be run from anywhere. An alternative, would be to ensure that the script and the utility it uses, are placed in the same directory and then direct the scripts to look for the utility in the same parent path as itself. Any suggestions between the two? Ideas on improving any other aspect of the utilities would be great too! Cheers, Teresa PS: To save the look up in case you don't have an install tree set up, passing ' --prefix=$PWD/installDirName' to frysk's configure makes one in the working directory. From elena.zannoni@oracle.com Tue Jul 31 23:16:00 2007 From: elena.zannoni@oracle.com (Elena Zannoni) Date: Tue, 31 Jul 2007 23:16:00 -0000 Subject: my schedule Message-ID: <46AFC28C.6080900@oracle.com> Just a FYI, I will not be attending the next two meetings, as I will be traveling. Regards elena From pmuldoon@redhat.com Tue Jul 31 23:34:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 31 Jul 2007 23:34:00 -0000 Subject: frysk-core/frysk/util ChangeLog CoredumpAction ... In-Reply-To: <20070731232332.21734.qmail@sourceware.org> References: <20070731232332.21734.qmail@sourceware.org> Message-ID: <46AFC6F0.2030606@redhat.com> Awhile back, when we were first working on fcore, Yong Zheng from IBM came up with the idea what we make a factory for the note segments and other various architecture specific sections. This would allow us to separate the architecture specific sections into their own classes. For reasons I cannot remember, we did not move that way and continued using one class. I've not heard from Yong in awhile, but credit where credit is due for the original idea. I re-factored these classes last week, created the factory and client classes and tested them on x86 and x86_64. If someone has PPC32 and PPC64 hardware, please let me know the results. I'm not sure all these client classes belong in the util/ namespace, and will likely be moved somewhere more appropriate in the future. This, and the re-factor, is part one of the CoredumpAction improvements. Now the code is cleaner, the next step it to move towards a streaming model for segments Regards Phil pmuldoon@sourceware.org wrote: > CVSROOT: /cvs/frysk > Module name: frysk-core > Changes by: pmuldoon@sourceware.org 2007-07-31 23:23:32 > > Modified files: > frysk/util : ChangeLog CoredumpAction.java > Added files: > frysk/util : LinuxElfCorefile.java > LinuxElfCorefileFactory.java > LinuxElfCorefilePPC32.java > LinuxElfCorefilePPC32on64.java > LinuxElfCorefilePPC64.java > LinuxElfCorefilex86.java > LinuxElfCorefilex8664.java > > Log message: > 2007-07-31 Phil Muldoon > > * CoredumpAction.java: Rewritten and Refactored to > LinuxElfCorefile.java. > * LinuxElfCorefileFactory.java: New. Return correct core > file back-end. > * LinuxCoreFile.java: New file. > * LinuxCoreFilex86.java: New file. > * LinuxCoreFilex8664.java: New file. > * LinuxCoreFilePPC32.java: New file. > * LinuxCoreFilePPC32On64.java: New file. > * LinuxCoreFilePPC64.java: New file. > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/util/LinuxElfCorefile.java.diff?cvsroot=frysk&r1=NONE&r2=1.1 > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/util/LinuxElfCorefileFactory.java.diff?cvsroot=frysk&r1=NONE&r2=1.1 > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/util/LinuxElfCorefilePPC32.java.diff?cvsroot=frysk&r1=NONE&r2=1.1 > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/util/LinuxElfCorefilePPC32on64.java.diff?cvsroot=frysk&r1=NONE&r2=1.1 > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/util/LinuxElfCorefilePPC64.java.diff?cvsroot=frysk&r1=NONE&r2=1.1 > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/util/LinuxElfCorefilex86.java.diff?cvsroot=frysk&r1=NONE&r2=1.1 > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/util/LinuxElfCorefilex8664.java.diff?cvsroot=frysk&r1=NONE&r2=1.1 > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/util/ChangeLog.diff?cvsroot=frysk&r1=1.154&r2=1.155 > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/util/CoredumpAction.java.diff?cvsroot=frysk&r1=1.18&r2=1.19 > > From pmuldoon@redhat.com Tue Jul 31 23:50:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 31 Jul 2007 23:50:00 -0000 Subject: Regs command In-Reply-To: <1185846259.9874.18.camel@multics.rdu.redhat.com> References: <46AE41AD.601@redhat.com> <1185846259.9874.18.camel@multics.rdu.redhat.com> Message-ID: <46AFCAC3.1080309@redhat.com> Stan Cox wrote: > Nice. Could we also have hex output as with gdb's "info registers"? > Is there an fhpd request "regs"? If not would "registers" be a more > descriptive name? > Yes, I would find hex more useful, too. I guess we could go a few ways here. Have a fhpd wide format command (to switch between decimal, hex, binary, octal); have the regs print out hex with the decimal equivalent in brackets, or just print out hex. The biggie for me is hex output. Regards Phil From pmuldoon@redhat.com Wed Aug 1 00:18:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Wed, 01 Aug 2007 00:18:00 -0000 Subject: Debuginfo utilities added In-Reply-To: <46AFB0B7.1040806@redhat.com> References: <46AFB0B7.1040806@redhat.com> Message-ID: <46AFD149.1030900@redhat.com> Teresa Thomas wrote: > I have just merged my branch with the main branch and committed the > changes. As mentioned earlier, I've added two new related utilities in > frysk/frysk-core/bindir: > > 1) fdebuginfo - which lists the debuginfo paths for the > (attached) process' modules. Its output format is a simple list of > module names, followed by their debuginfo paths. Paths for ones that > do not contain debuginfo, are shown as "---". Awesome, these tools I've been looking forward to for awhile! Future suggestion: fdebuginfo that does the same as but for a latent, inanimate executable on disk. > 2) fdebugrpm - which is a bash script that allows you to > install the missing debuginfo packages using yum. This lists the > missing debuginfo packages, and gives the user a choice to install them. I tried this but got: [pmuldoon@localhost bindir]$ sudo ./fdebugrpm 2788 Missing Debuginfo package(s) ============================ bash-debuginfo glibc-debuginfo ncurses-debuginfo Do you wish to install the above packages? [y/n]: y Loading "installonlyn" plugin Setting up Install Process Parsing package install arguments Nothing to do No debuginfo packages were installed. I then noticed that in: /etc/yum.repos.d//fedora-updates.repo The "enabled" flag was = 0. So I set it to 1. That installed the glibc-debuginfo but not the ncurses and bash debuginfo packages. I then looked at fedora.repo and the enabled flag was set to 0 there as well. Set that to 1 and it all worked. Anyway I mention this, as it seems debuginfo repos are off by default. If that is so, then some blurb in the man page would be help the user here. I really like this utility, though. Very useful! One last item for improvement/discussion. Both fstack and fcore are very thin wrappers around StrackTraceAction and CoredumpAction classes respectively. The reason for this is that these classes can then be called from other utilities, even triggered as part of an observable action, or via fhpd. Would the same go for extruding classes from fdebug*, and making the fdebug* executables a thin layer around a utility class? Regards Phil From pmuldoon@redhat.com Wed Aug 1 00:27:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Wed, 01 Aug 2007 00:27:00 -0000 Subject: Make CoredumpAction use Task.getRegisterBanks() In-Reply-To: <1185883408.3653.106.camel@dijkstra.wildebeest.org> References: <1185814384.3674.36.camel@dijkstra.wildebeest.org> <46AE238B.5020204@redhat.com> <1185883408.3653.106.camel@dijkstra.wildebeest.org> Message-ID: <46AFD351.6030004@redhat.com> Mark Wielaard wrote: > > For ptrace/proc based Tasks there are basically 4 register banks (not > all of them used on all architectures) the Isa provides a mapping from > the actual register names to the bank and offset inside it. The four > banks are the regular registers (gotten through PTRACE_GETREGS), the > general floating point registers (gotten through PTRACE_GETFPREGS), the > extended floating point registers such like sse xmm registers (gotten > through PTRACE_getXFPREGS) and the other registers (gotten through the > start of USR memory space) that cover things like debug control > registers found by the Isa through the mapping in sys/user.h (some of > the other register banks are actually also contained in this one). > > Does this map somewhat to how core files handle the register banks, so > you can just dump/read these banks from them? > Pretty much other than General Purpose registers which needs to be accessed independently via getRegisterByName(). The the rest are just dumped wholesale into the notes, and in that instance accessed via task.getRegisterBanks(). I think, going forward access to the raw memory for each register bank, and also a getRegisterByName() function (which is the functionality we have now) is needed, and probably will be down the line. Regards Phil From timoore@redhat.com Wed Aug 1 09:10:00 2007 From: timoore@redhat.com (Tim Moore) Date: Wed, 01 Aug 2007 09:10:00 -0000 Subject: frysk meeting 2007-08-01 In-Reply-To: <46AF7C3A.90509@redhat.com> References: <46AF3DBE.1020802@redhat.com> <46AF7C3A.90509@redhat.com> Message-ID: <46B04E06.7060102@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Cagney wrote: > + discuss switching to git and/or mercurial > As further grist for the mill, and hopefully not gasoline on the fire, here is our colleague Jim Meyering's view on git vs. hg: http://meyering.net/dVCS/ . He's even more adamant about it in person :) Tim > > Andrew Cagney wrote: >> All welcome, please contact me off list for dial in information. >> >> This week; walking through one or more off: >> -> fstack >> -> disassembler (again :-) >> -> fdebuginfo >> > - -- Red Hat France SARL, 171 Avenue Georges Clemenceau 92024 Nanterre Cedex, France. Siret n?? 421 199 464 00056 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGsE4FeDhWHdXrDRURAiXHAKCXIJ0r2JqLjcTl7SF7buptZ5GtKACfQy/h 6lZVxyUQGkwkEy1nJUwcoqM= =GMGp -----END PGP SIGNATURE----- From cagney@redhat.com Thu Aug 2 02:58:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 02 Aug 2007 02:58:00 -0000 Subject: putting Ptrace back to 64-bit Message-ID: <46B14863.60601@redhat.com> Mark, I don't understand the rationale behind this change: 2007-07-30 Mark Wielaard * FileDescriptor.java (read): Make start and length ints. (write): Likewise. * Ptrace.java (peek): Make length and offset ints. * StatelessFile.java (pread): Make start and length ints. (pwrite): Likewise. * TestFileDescriptor.java (IO.op): Likewise. (assertArrayIndexOutOfBounds): Likewise. (testReadOutOfBounds): Likewise. (testWriteOutOfBounds): Likewise. * TestPtrace.java (verifyOutOfBounds): Make length and offset ints. * TestStatelessFile.java: Make start and length ints. * cni/Errno.cxx (verifyBounds): Make start and length ints. * cni/Errno.hxx: Likewise. * cni/FileDescriptor.cxx (read): Make start and length jints. (write): Likewise. * cni/Ptrace.cxx (peek): Make length and offset jints. * cni/StatelessFile.cxx (pread): Make start and length jints. (pwrite): Likewise. It forces calling code to contend with Java's bone-head "int" is 32-bits and be damed. Having all of these "long", which I only just went through and cleaned up, avoided all that. The only thing missing was for inua to be matched to this style. Andrew From mark@klomp.org Thu Aug 2 08:07:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Thu, 02 Aug 2007 08:07:00 -0000 Subject: [patch] IA32 subsyscall list fixes In-Reply-To: <46AF55A9.5060902@redhat.com> References: <1185879001.3653.75.camel@dijkstra.wildebeest.org> <46AF55A9.5060902@redhat.com> Message-ID: <1186042014.15044.33.camel@dijkstra.wildebeest.org> Hi Andrew, On Tue, 2007-07-31 at 11:30 -0400, Andrew Cagney wrote: > You mentioned an off-by-one error in the syscall code. Is that now > being tested? If you ftrace FryskGui as in the bug report (or any other non-trivial program) yes. There have also been guards added to the code to test that this cannot be happening again. Subsyscalls are IA32 specific and aren't explicitly covered by the auditlibs tests as far as I can see (except for the major syscall numbers of course). If you want you can try to add them explicitly to TestSyscallsWithAudit given auditlib code to detect them (I don't know if auditlib can provide that info yet though). If not, let me know and I add it to my list to investigate. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Thu Aug 2 08:12:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Thu, 02 Aug 2007 08:12:00 -0000 Subject: Testing frysk.testbed.Funit* In-Reply-To: <46AF5BDE.6000806@redhat.com> References: <46AE081A.8070503@redhat.com> <1185876171.3653.64.camel@dijkstra.wildebeest.org> <46AF5BDE.6000806@redhat.com> Message-ID: <1186042314.15044.35.camel@dijkstra.wildebeest.org> Hi Andrew, On Tue, 2007-07-31 at 11:57 -0400, Andrew Cagney wrote: > Mark Wielaard wrote: > > On Mon, 2007-07-30 at 11:47 -0400, Andrew Cagney wrote: > > > >> I'm looking at ways to more directly test the frysk.testbed.Funit* > >> classes (e.g., FunitExec, DetachedAckProcess) that wrap > >> PKGLIBDIR/funit-* utilities, but am finding that the most effective > >> route is to use frysk.proc's framework - duplicating the existing > >> frysk.proc tests exercising frysk.proc functionality that is effectively > >> testing that code. > >> > >> I could duplicate the tests but it seems redundant. Any thoughts on a > >> strategy? > > > > I might be missing the exact cases you want to test. But can't you just > > audit the current frysk.proc tests to see if they cover all relevant > > cases already and if not add one or two tests to the existing proc tests > > so all cases are covered? That way you will also extend the real proc > > tests to handle more cases catching two birds with one stone (if that > > isn't a terribly political incorrect saying). > > > you describe the current state of play; frysk.proc code is testing both > itself internally and the funit tools implicitly. There's nothing > directly testing units such as FunitExecOffspring; instead it is done > implicitly via frysk.proc. That is great when it works, but not so > great when tests fail as differentiating between an FunitExecOffspring > or frysk.proc breakage that caused the fail isn't possible. Tests that not just cover the bare essentials, but test the code in actual use scenarios are very important. It makes sure that the code is tested as it will actually be used. And in this case, if you find something not covered, the proc code gets also more tests. As you say that is great if it works. But I get the feeling that is not enough for your current strategy. > As a contrasting example. Say we find the UI is crashing and track it > down to a dwarf binding bug. What we do is add a test-case to the dwarf > bindings testing the problem (which contains the root cause of the > problem); and then fix it. Is the core code is now being tested, we're > confident that our problem won't return. Is there an effective way to > do that here with the Funit* bindings? Right. That is what I am actually suggesting. Make sure that there are enough tests in proc that you feel confident that everything under funit is covered. Then if some issue is found anyway later on and it is tracked down to funit then just add an extra test there when you fix the problem so you can be confident it won't return. Besides that you have to fall back on your suggestion, slightly redundant, test duplication I am afraid. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Thu Aug 2 08:28:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Thu, 02 Aug 2007 08:28:00 -0000 Subject: Make CoredumpAction use Task.getRegisterBanks() In-Reply-To: <46AFD351.6030004@redhat.com> References: <1185814384.3674.36.camel@dijkstra.wildebeest.org> <46AE238B.5020204@redhat.com> <1185883408.3653.106.camel@dijkstra.wildebeest.org> <46AFD351.6030004@redhat.com> Message-ID: <1186043315.15044.46.camel@dijkstra.wildebeest.org> On Tue, 2007-07-31 at 19:26 -0500, Phil Muldoon wrote: > Mark Wielaard wrote: > > > > For ptrace/proc based Tasks there are basically 4 register banks (not > > all of them used on all architectures) the Isa provides a mapping from > > the actual register names to the bank and offset inside it. The four > > banks are the regular registers (gotten through PTRACE_GETREGS), the > > general floating point registers (gotten through PTRACE_GETFPREGS), the > > extended floating point registers such like sse xmm registers (gotten > > through PTRACE_getXFPREGS) and the other registers (gotten through the > > start of USR memory space) that cover things like debug control > > registers found by the Isa through the mapping in sys/user.h (some of > > the other register banks are actually also contained in this one). > > > > Does this map somewhat to how core files handle the register banks, so > > you can just dump/read these banks from them? > > > > Pretty much other than General Purpose registers which needs to be > accessed independently via getRegisterByName(). The the rest are just > dumped wholesale into the notes, and in that instance accessed via > task.getRegisterBanks(). Thanks. So this seems slightly different from how we do things with ptrace/proc where we can have multiple different register banks (for floating point, extended floating point and control/debug registers). We might be able to always just use the USR address space to get at all of those together in one go (I don't actually know why we don't do that, or why ptrace provides different ways to access the same register sets). > I think, going forward access to the raw memory for each register bank, > and also a getRegisterByName() function (which is the functionality we > have now) is needed, and probably will be down the line. If we can match up the raw memory for each register bank between ptrace/proc and core files from Task that would be ideal. Then the Isa can just do the getRegisterByName() mapping. I'll watch your rewrite of the core file stuff and see if this makes things easier and clearer (I guess it will). Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Thu Aug 2 08:40:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Thu, 02 Aug 2007 08:40:00 -0000 Subject: putting Ptrace back to 64-bit In-Reply-To: <46B14863.60601@redhat.com> References: <46B14863.60601@redhat.com> Message-ID: <1186043998.15044.47.camel@dijkstra.wildebeest.org> Hi Andrew, On Wed, 2007-08-01 at 22:58 -0400, Andrew Cagney wrote: > I don't understand the rationale behind this change: It was proposed and explained as a follow up for the LogicalMemoryBuffer under "A couple of things to note, questions and upcoming work" at: http://sourceware.org/ml/frysk/2007-q3/msg00163.html And the rationale was again added when the actual patch to implement it was posted: http://sourceware.org/ml/frysk/2007-q3/msg00216.html > It forces calling code to contend with Java's bone-head "int" is 32-bits > and be damed. No, the patch carefully only changes those calls that take a 32-bit (actually positive "int" byte[]) container in the first place so that the calling code is consistent and calls to these methods get flagged at compile time if they provide inconsistent arguments. None of the arguments that actually are 64-bit were changed of course. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Thu Aug 2 11:26:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Thu, 02 Aug 2007 11:26:00 -0000 Subject: [patch] LogicalMemoryBuffer In-Reply-To: <1184932926.3611.58.camel@dijkstra.wildebeest.org> References: <1184932926.3611.58.camel@dijkstra.wildebeest.org> Message-ID: <1186053948.15044.61.camel@dijkstra.wildebeest.org> Hi, On Fri, 2007-07-20 at 14:02 +0200, Mark Wielaard wrote: > - LogicalMemoryBuffer is a filter on top of AddressSpaceByteBuffer but > really should be on top of MemorySpaceByteBuffer which is more > effecient. The used to be interface compatible, but a recent change to > MemorySpaceByteBuffer changed that and made that it less easy to wrap. > MemorySpaceByteBuffer is really just an optimization of > AddressSpaceByteBuffer (in the case of AddressSpace.TEXT/DATA) and all > code should go through the optimized path (StateLessFile) for accessing > memory if the AddressSpace allows it. So I am going to merge the two > (and fix up the places that currently use the slow path). Then I'll also > add the ByteBuffer.get() optimization that Chris pointed out. This patch implements the above and fixes bug #4827 and #4760 by adding a bulk put ByteBuffer method as Andrew suggested and using the StateLessFile support for this as Chris implemented. It also updates RegisterSetByteBuffer in the same way. LogicalMemoryBuffer is now marked as read only to signal that to change memory you should go through the raw memory view (if you need this, then you are probably interfering with the breakpoint support, so need to update that code to deal with other ways the underlying memory could change). Various methods have been updated to use the bulk put methods now. frysk-core/frysk/proc/live/ChangeLog 2007-08-02 Mark Wielaard * AddressSpaceByteBuffer.java (mem): New field. (pokesRequest): Likewise. (AddressSpaceByteBuffer): Initialize mem and pokesRequest. (PeeksRequest.peek): New method. (PeeksRequest.execute): use peek(). (PeeksRequest.request): Likewise. (PokesRequest): New inner class. (poke): New method. * LinuxTask.java (getRawMemory): Use AddressSpaceByteBuffer. * LogicalMemoryBuffer.java (poke): New methods marked as unsupported. * MemorySpaceByteBuffer.java: Removed. * RegisterSetByteBuffer.java (peek): Use System.arraycopy(). (poke): New method. * TestMemorySpaceByteBuffer.java: Removed. * TestByteBuffer.java: Merged in TestMemorySpaceByteBuffer tests, made test more generic to test all possible buffers, add bulk put tests. frysk-core/frysk/proc/ChangeLog 2007-08-02 Mark Wielaard * Breakpoint.java (set): Use raw memory and bulk put method. (reset): Likewise. * BreakpointAddresses.java: Make public. * Instruction.java (setupExecuteOutOfLine): use raw memory and bulk put method. frysk-sys/inua/ChangeLog 2007-08-02 Mark Wielaard * ByteBuffer.java (put(byte[],int,int)): New bulk put method. (put(byte[])): likewise. The biggest part of the patch is actually the removal of now redundant classes and the addition of more tests and making those tests more generic to test all possible ByteBuffers. Yeah, less code, more tests! :) All new ByteBuffer tests PASS and no new regressions as tested on x86 (F7) and x86_64 (FC6). Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: buf.patch Type: text/x-patch Size: 32643 bytes Desc: not available URL: From cagney@redhat.com Thu Aug 2 12:37:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 02 Aug 2007 12:37:00 -0000 Subject: putting Ptrace back to 64-bit In-Reply-To: <1186043998.15044.47.camel@dijkstra.wildebeest.org> References: <46B14863.60601@redhat.com> <1186043998.15044.47.camel@dijkstra.wildebeest.org> Message-ID: <46B1D016.909@redhat.com> Mark Wielaard wrote: > Hi Andrew, > > On Wed, 2007-08-01 at 22:58 -0400, Andrew Cagney wrote: > >> I don't understand the rationale behind this change: >> > > It was proposed and explained as a follow up for the LogicalMemoryBuffer > under "A couple of things to note, questions and upcoming work" at: > http://sourceware.org/ml/frysk/2007-q3/msg00163.html > And the rationale was again added when the actual patch to implement it > was posted: http://sourceware.org/ml/frysk/2007-q3/msg00216.html > Please run such things directly past me. > >> It forces calling code to contend with Java's bone-head "int" is 32-bits >> and be damed. >> > > That is Java's 32-bit bonehead ism. This exports a 64-bit interface; we'll keep it that way. > No, the patch carefully only changes those calls that take a 32-bit > (actually positive "int" byte[]) container in the first place so that > the calling code is consistent and calls to these methods get flagged at > compile time if they provide inconsistent arguments. None of the > arguments that actually are 64-bit were changed of course. > > Cheers, > > Mark > From mark@klomp.org Thu Aug 2 14:00:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Thu, 02 Aug 2007 14:00:00 -0000 Subject: putting Ptrace back to 64-bit In-Reply-To: <46B1D016.909@redhat.com> References: <46B14863.60601@redhat.com> <1186043998.15044.47.camel@dijkstra.wildebeest.org> <46B1D016.909@redhat.com> Message-ID: <1186063226.15044.76.camel@dijkstra.wildebeest.org> Hi Andrew, On Thu, 2007-08-02 at 08:37 -0400, Andrew Cagney wrote: > Mark Wielaard wrote: > > On Wed, 2007-08-01 at 22:58 -0400, Andrew Cagney wrote: > >> I don't understand the rationale behind this change: > > > > It was proposed and explained as a follow up for the LogicalMemoryBuffer > > under "A couple of things to note, questions and upcoming work" at: > > http://sourceware.org/ml/frysk/2007-q3/msg00163.html > > And the rationale was again added when the actual patch to implement it > > was posted: http://sourceware.org/ml/frysk/2007-q3/msg00216.html > > Please run such things directly past me. I am happy for people to review my patches before committing. But you have to give me some guidance here since till now we didn't have any formal reviews, but were relying on unit tests to catch any badness. In this case I thought it was a simple cleanup refactoring to make the real work that I was doing easier and the code safer (as explained in that first email). What kind of changes do you want to have reviewed first and by who. Do you want people to be CCed on such patches? Can't we just make it so that if a patch is posted to the list anybody can review it to make sure it is sane? Cheers, Mark From cagney@redhat.com Thu Aug 2 23:51:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 02 Aug 2007 23:51:00 -0000 Subject: simplistic examine command Message-ID: <46B26DF8.6090202@redhat.com> FYI, I've added a very simplistic implementation of the examine command. My main purpose is to help illustrate the differences between "print" and "examine" by providing more concrete code. It is far from finished (it should list location addresses et.al.) The main thing to note is the implementation vis: Value v = <> ByteBuffer b = v.getLocation().getByteBuffer() for (int i = 0; i < b.capacity(); i++) print b.getByte(i) Thus examine is about examining the value's underlying data in different formats, for instance, consider: (fhpd) print int_22 22 (fhpd) examine int_22 0: 22 1: 0 2: 0 3: 0 The print command, on the other hand, is much simpler. it's implementation is meant to be: Format format = Format.??? Value v = <> v.toPrint(printWriter, getMemory(), format) For instance: (fhpd) print struct_s --format x { int a = 0x1; int b = 0x2 } (Ok, it doesn't at present, there's some stray code to delete :-). That is it always displays a value according to that value's type. But possibly with the formating of fields changed slightly. This is different to gdb's examine command which can only examine memory, and not arbitrary values that are possibly in memory and/or registers. Andrew From pmuldoon@redhat.com Fri Aug 3 14:03:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 03 Aug 2007 14:03:00 -0000 Subject: [patch] LogicalMemoryBuffer In-Reply-To: <1186053948.15044.61.camel@dijkstra.wildebeest.org> References: <1184932926.3611.58.camel@dijkstra.wildebeest.org> <1186053948.15044.61.camel@dijkstra.wildebeest.org> Message-ID: <46B335A4.6020503@redhat.com> Mark Wielaard wrote: > Hi, > > On Fri, 2007-07-20 at 14:02 +0200, Mark Wielaard wrote: > >> - LogicalMemoryBuffer is a filter on top of AddressSpaceByteBuffer but >> really should be on top of MemorySpaceByteBuffer which is more >> effecient. The used to be interface compatible, but a recent change to >> MemorySpaceByteBuffer changed that and made that it less easy to wrap. >> MemorySpaceByteBuffer is really just an optimization of >> AddressSpaceByteBuffer (in the case of AddressSpace.TEXT/DATA) and all >> code should go through the optimized path (StateLessFile) for accessing >> memory if the AddressSpace allows it. So I am going to merge the two >> (and fix up the places that currently use the slow path). Then I'll also >> add the ByteBuffer.get() optimization that Chris pointed out. >> Can you write up the difference between Logical and Raw Memory? How is Raw memory exported? If a break-point has been added to memory 0x123434 is the map marked as written in RawMemory? Regards Phil From pmuldoon@redhat.com Fri Aug 3 14:18:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 03 Aug 2007 14:18:00 -0000 Subject: Make CoredumpAction use Task.getRegisterBanks() In-Reply-To: <1186043315.15044.46.camel@dijkstra.wildebeest.org> References: <1185814384.3674.36.camel@dijkstra.wildebeest.org> <46AE238B.5020204@redhat.com> <1185883408.3653.106.camel@dijkstra.wildebeest.org> <46AFD351.6030004@redhat.com> <1186043315.15044.46.camel@dijkstra.wildebeest.org> Message-ID: <46B33940.6000005@redhat.com> Mark Wielaard wrote: > > Thanks. So this seems slightly different from how we do things with > ptrace/proc where we can have multiple different register banks (for > floating point, extended floating point and control/debug registers). We > might be able to always just use the USR address space to get at all of > those together in one go (I don't actually know why we don't do that, or > why ptrace provides different ways to access the same register sets). > > Apologies for the delay in replying. For the FP and fpxregs (which I am writing code for right now), I just take the entire register buffer and dump it wholesale into the appropriate note in the core file. For GP registers there are some cross-isa issues (mainly in PPC) that require the code to pick them individually, sort them into order, them populate them as part of another note, the elf_prstatus note. This is an important distinction as GP registers do not have their own separate note area in core files, but are part of the thread elf_prstatus note. That is why both raw memory banks, and getRegisterByName are needed. > If we can match up the raw memory for each register bank between > ptrace/proc and core files from Task that would be ideal. Then the Isa > can just do the getRegisterByName() mapping. I'll watch your rewrite of > the core file stuff and see if this makes things easier and clearer (I > guess it will). > The two requirements needed for core files are: 1) Access to the raw memory behind the register via a ByteBuffer 2) Access to a logical method of getting registers by name, like getRegisterByName() Regards Phil From mark@klomp.org Mon Aug 6 09:17:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 06 Aug 2007 09:17:00 -0000 Subject: [patch] LogicalMemoryBuffer In-Reply-To: <46B335A4.6020503@redhat.com> References: <1184932926.3611.58.camel@dijkstra.wildebeest.org> <1186053948.15044.61.camel@dijkstra.wildebeest.org> <46B335A4.6020503@redhat.com> Message-ID: <1186391866.3766.24.camel@dijkstra.wildebeest.org> Hi Phil, On Fri, 2007-08-03 at 09:03 -0500, Phil Muldoon wrote: > Mark Wielaard wrote: > > On Fri, 2007-07-20 at 14:02 +0200, Mark Wielaard wrote: > >> - LogicalMemoryBuffer is a filter on top of AddressSpaceByteBuffer but > >> really should be on top of MemorySpaceByteBuffer which is more > >> effecient. The used to be interface compatible, but a recent change to > >> MemorySpaceByteBuffer changed that and made that it less easy to wrap. > >> MemorySpaceByteBuffer is really just an optimization of > >> AddressSpaceByteBuffer (in the case of AddressSpace.TEXT/DATA) and all > >> code should go through the optimized path (StateLessFile) for accessing > >> memory if the AddressSpace allows it. So I am going to merge the two > >> (and fix up the places that currently use the slow path). Then I'll also > >> add the ByteBuffer.get() optimization that Chris pointed out. > >> > > Can you write up the difference between Logical and Raw Memory? How is > Raw memory exported? If a break-point has been added to memory 0x123434 > is the map marked as written in RawMemory? Good questions. See also the Task getRawMemory() interface documentation. getMemory() and getRawMemory() are somewhat independent of the MemoryMaps returned by getMaps(). You can get the actual bytes of the address ranges given in the MemoryMap through either the ByteBuffer returned by getMemory(), which gives you the logical memory view (without any "artificial" changes made by frysk-core) or through the ByteBuffer returned by getRawMemory() that includes also any changes to the memory made by frysk-core. Since there is only one getMaps() variant the flags set on the returned MemoryMaps correspond to the "raw" memory view. So a MemoryMap could be marked as written to, but if you access its content through the getMemory() ByteBuffer you would still not see the frysk-core change. If it is beneficial for your use case we could add an extra flag to MemoryMap saying whether or not it (also) contains changes were made by frysk-core. Note however that the kernel doesn't track the "why" of a write to the map, so it doesn't distinguish between whether a monitoring app like frysk did it, or whether the application itself or the kernel wrote to the map. And as Roland said there is no way to "reverse" a write, once written, even if you put back the original contents later, it will always be marked as written by the kernel. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Mon Aug 6 10:03:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 06 Aug 2007 10:03:00 -0000 Subject: Make CoredumpAction use Task.getRegisterBanks() In-Reply-To: <46B33940.6000005@redhat.com> References: <1185814384.3674.36.camel@dijkstra.wildebeest.org> <46AE238B.5020204@redhat.com> <1185883408.3653.106.camel@dijkstra.wildebeest.org> <46AFD351.6030004@redhat.com> <1186043315.15044.46.camel@dijkstra.wildebeest.org> <46B33940.6000005@redhat.com> Message-ID: <1186394612.3766.37.camel@dijkstra.wildebeest.org> Hi Phil, I tried to look up the "core file spec" but it seems no such thing exits you just need to grep through binutils, gdb and kernel sources to figure it all out it seems. Actually various searches all seem to finally point to your frysk core file support (You are the expert now!) :) On Fri, 2007-08-03 at 09:18 -0500, Phil Muldoon wrote: > For the FP and fpxregs (which I am writing code for right now), I just > take the entire register buffer and dump it wholesale into the > appropriate note in the core file. ACK. I saw bug #4890. It looks like whether or not the fp and fpx register banks exist in the first place is platform specific. But I guess this is another one of these "what does the kernel dump and how does gdb read it back in" types of questions... > > If we can match up the raw memory for each register bank between > > ptrace/proc and core files from Task that would be ideal. Then the Isa > > can just do the getRegisterByName() mapping. I'll watch your rewrite of > > the core file stuff and see if this makes things easier and clearer (I > > guess it will). > > > The two requirements needed for core files are: > > 1) Access to the raw memory behind the register via a ByteBuffer > 2) Access to a logical method of getting registers by name, like > getRegisterByName() And it can then provide those back for the core file as Task consumer as right? The question I am trying to answer is whether or not we can move getRegisterBankBuffers() fully into the (ptrace) Task and let the Isa use a call on the Task to provide the getRegisterByName() mapping functionality from bank/numer to register name. Currently Task (or any other Task consumer can) call back into the Isa to get at the actual register banks, which is messy (and will produce the wrong results for core file backed Tasks). So if we can match up the results of Task.getRegisterBanks()/sendrecRegisterBanks() between ptrace/core Task implementations then we could clean the Isa interface up and make the Isa/Task user always get the correct result. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Mon Aug 6 14:45:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 06 Aug 2007 14:45:00 -0000 Subject: Adding and deleting observations multiple times Message-ID: <1186411498.3766.46.camel@dijkstra.wildebeest.org> Hi, Petr found a bug with adding and observer multiple times and then deleting it. He even wrote a testcase for it. The issue was that you could add an observation for different events (or in his particular case watch an breakpoint on multiple addresses) but that Proc doesn't know about this and treats the double add and one delete as if the observer should be deleted completely, so if you delete it for the another event (address) the Proc sanity check kicks in and flags it as a double delete. The following patch fixes that (and makes the test case slightly more deterministic): 2007-08-06 Mark Wielaard Fixes bug #4894 * Proc.java (observations): Turn into a Collection that can contain an observer multiple times. * TestTaskObserverCode.java (testCodeRemovedInHit): Explicitly wait for add and delete. With this patch the test case now succeeds and no regressions (tested on x86_64 FC6). Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: add-delete-observation.patch Type: text/x-patch Size: 2187 bytes Desc: not available URL: From mark@klomp.org Mon Aug 6 15:07:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 06 Aug 2007 15:07:00 -0000 Subject: frysk meeting 2007-08-01 demo typescript Message-ID: <1186412836.3766.53.camel@dijkstra.wildebeest.org> Hi, Here is the typescript of the demo we ran on 2007-08-01. I only edited it slightly to add some comments between the demos. Cheers, Mark ----------------------------------------------------------------------------- Sami showing the frame decorators to show inlined funcions on the call stack. (This was done by patching the source slightly to put out more debug stuff) ----------------------------------------------------------------------------- $ cd src/frysk-obj/frysk-core $ ./TestRunner frysk.debuginfo.TestFrameDebugInfo Running testFrameDebugInfoStackTrace(frysk.debuginfo.TestFrameDebugInfo) ...PASS Running testFrameAdjustedAddress(frysk.debuginfo.TestFrameDebugInfo) ...UNRESOLVED http://sourceware.org/bugzilla/show_bug.cgi?id=4676 Running testFrameScopes(frysk.debuginfo.TestFrameDebugInfo) ...UNRESOLVED http://sourceware.org/bugzilla/show_bug.cgi?id=4677 Running testFrameScopesWorkAround(frysk.debuginfo.TestFrameDebugInfo) ...PASS Running testGetInlinedSubroutines(frysk.debuginfo.TestFrameDebugInfo) ...DebugInfoFrame.getInlnedSubprograms() DW_TAG_lexical_block DebugInfoFrame.getInlnedSubprograms() DW_TAG_inlined_subroutine DebugInfoFrame.getInlnedSubprograms() DW_TAG_lexical_block DebugInfoFrame.getInlnedSubprograms() DW_TAG_inlined_subroutine DebugInfoFrame.getInlnedSubprograms() DW_TAG_lexical_block DebugInfoFrame.getInlnedSubprograms() DW_TAG_inlined_subroutine DebugInfoFrame.getInlnedSubprograms() DW_TAG_subprogram DebugInfoFrame.getInlnedSubprograms() DW_TAG_compile_unit PASS Running testVirtualDebugInfoStackTrace(frysk.debuginfo.TestFrameDebugInfo) ...DebugInfoFrame.getInlnedSubprograms() DW_TAG_lexical_block DebugInfoFrame.getInlnedSubprograms() DW_TAG_inlined_subroutine DebugInfoFrame.getInlnedSubprograms() DW_TAG_lexical_block DebugInfoFrame.getInlnedSubprograms() DW_TAG_inlined_subroutine DebugInfoFrame.getInlnedSubprograms() DW_TAG_lexical_block DebugInfoFrame.getInlnedSubprograms() DW_TAG_inlined_subroutine DebugInfoFrame.getInlnedSubprograms() DW_TAG_subprogram DebugInfoFrame.getInlnedSubprograms() DW_TAG_compile_unit Task #2789 #0 0x080483af in third(int arg3 = 6978720) /home/mark/src/frysk-obj/frysk-core/../../frysk/frysk-core/frysk/pkglibdir/funit-inlined.c#6 int var3 = < value unavailable at pc=0x80483af> line#< error > * a = < value unavailable at pc=0x80483af> line#< error > #1 0x080483af in second(int arg2 = 6978720) /home/mark/src/frysk-obj/frysk-core/../../frysk/frysk-core/frysk/pkglibdir/funit-inlined.c#6 int var2 = < value unavailable at pc=0x80483af> line#< error > int var3 = < value unavailable at pc=0x80483af> line#< error > * a = < value unavailable at pc=0x80483af> line#< error > #2 0x080483af in first(int arg1 = 6978720) /home/mark/src/frysk-obj/frysk-core/../../frysk/frysk-core/frysk/pkglibdir/funit-inlined.c#6 int var1 = < value unavailable at pc=0x80483af> line#< error > int var2 = < value unavailable at pc=0x80483af> line#< error > int var3 = < value unavailable at pc=0x80483af> line#< error > * a = < value unavailable at pc=0x80483af> line#< error > #3 0x080483af in main () from /home/mark/src/frysk-obj/frysk-core/frysk/pkglibdir/funit-inlined #4 0x006c0f70 in __libc_start_main () from /lib/libc-2.6.so #5 0x080482c1 in _start () from /home/mark/src/frysk-obj/frysk-core/frysk/pkglibdir/funit-inlined PASS Running testValues(frysk.debuginfo.TestFrameDebugInfo) ...PASS Running testColNumbers(frysk.debuginfo.TestFrameDebugInfo) ...PASS Running testLineNumbers(frysk.debuginfo.TestFrameDebugInfo) ...PASS Time: 0.158 There were 2 unresolved: http://sourceware.org/bugzilla/show_bug.cgi?id=4677 http://sourceware.org/bugzilla/show_bug.cgi?id=4676 OK (9 tests) ---------------------------------------------------------------------------- [... A bash shell was started (pid = 2072) ...] ---------------------------------------------------------------------------- $ ./frysk/bindir/fhpd 2072 Attached to process 2072 (fhpd) disassemble -help disassemble [OPTIONS] [startAddress] || disassemble [-OPTIONS] disassemble Options: -i, -instructions-only only print the instruction portion not the parameters -t, -no-truncate don't truncate the number of instructions printed -s, -no-symbol don't print the symbol name Standard Options: -help print this help disassemble the function surrounding the current pc, the function surrounding a given address, or a range of functions. (fhpd) where #0 0x00110402 in __kernel_vsyscall () from [vdso] (fhpd) disassemble Dump of assembler code for function: __kernel_vsyscall 0x110400 <__kernel_vsyscall+0>: int $0x80 *0x110402 <__kernel_vsyscall+2>: ret End of assembly dump (fhpd) down #0 0x00110402 in __kernel_vsyscall () from [vdso] (fhpd) disassemble Dump of assembler code for function: __kernel_vsyscall 0x110400 <__kernel_vsyscall+0>: int $0x80 *0x110402 <__kernel_vsyscall+2>: ret End of assembly dump (fhpd) quit Quitting... --------------------------------------------------------------------------- [... Oops, that demo went wrong, no debug info available! ...] Which was a great oppertunity for Teresa to show her fdebuginfo stuff. --------------------------------------------------------------------------- $ ./fdebuginfo 2072 /lib/libnss_files-2.6.so --- /lib/ld-2.6.so --- /lib/libc-2.6.so --- /lib/libdl-2.6.so --- /lib/libtinfo.so.5.6 --- /bin/bash /usr/lib/debug/bin/bash.debug $ ./fdebugrpm 2072 Missing Debuginfo package(s) ============================ glibc-debuginfo ncurses-debuginfo Do you wish to install the above packages? [y/n]: y Password or swipe finger: Loading "installonlyn" plugin Setting up Install Process Parsing package install arguments fedora 100% |=========================| 2.1 kB 00:00 updates 100% |=========================| 1.9 kB 00:00 primary.sqlite.bz2 100% |=========================| 1.1 MB 00:03 Nothing to do --------------------------------------------------------------------------- [... Oops, no debug repo enabled by default. Darn. Install the packages listed above by hand then for now ...] --------------------------------------------------------------------------- $ sudo yum --enablerepo=fedora-debuginfo install glibc-debuginfo ncurses-debuginfo Loading "installonlyn" plugin Setting up Install Process Parsing package install arguments fedora-debuginfo 100% |=========================| 1.9 kB 00:00 Resolving Dependencies --> Running transaction check ---> Package ncurses-debuginfo.i386 0:5.6-6.20070303.fc7 set to be updated ---> Package glibc-debuginfo.i686 0:2.6-3 set to be updated --> Processing Dependency: glibc-debuginfo-common = 2.6-3 for package: glibc-debuginfo --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package glibc-debuginfo-common.i386 0:2.6-3 set to be updated ---> Package glibc-debuginfo.i686 0:2.6-3 set to be updated Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: glibc-debuginfo i686 2.6-3 fedora-debuginfo 6.1 M ncurses-debuginfo i386 5.6-6.20070303.fc7 fedora-debuginfo 1.1 M Installing for dependencies: glibc-debuginfo-common i386 2.6-3 fedora-debuginfo 12 M Transaction Summary ============================================================================= Install 3 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 19 M Is this ok [y/N]: y Downloading Packages: (1/3): glibc-debuginfo-2. 100% |=========================| 6.1 MB 00:20 (2/3): glibc-debuginfo-co 100% |=========================| 12 MB 00:35 (3/3): ncurses-debuginfo- 100% |=========================| 1.1 MB 00:03 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing: glibc-debuginfo-common ######################### [1/3] Installing: ncurses-debuginfo ######################### [2/3] Installing: glibc-debuginfo ######################### [3/3] Installed: glibc-debuginfo.i686 0:2.6-3 ncurses-debuginfo.i386 0:5.6-6.20070303.fc7 Dependency Installed: glibc-debuginfo-common.i386 0:2.6-3 Complete! $ ./frysk/bindir/fdebuginfo 2072 /lib/libnss_files-2.6.so /usr/lib/debug/lib/libnss_files-2.6.so.debug /lib/ld-2.6.so /usr/lib/debug/lib/ld-2.6.so.debug /lib/libc-2.6.so /usr/lib/debug/lib/libc-2.6.so.debug /lib/libdl-2.6.so /usr/lib/debug/lib/libdl-2.6.so.debug /lib/libtinfo.so.5.6 /usr/lib/debug/lib/libtinfo.so.5.6.debug /bin/bash /usr/lib/debug/bin/bash.debug $ ./frysk/bindir/fhpd 2072 Attached to process 2072 (fhpd) where #0 0x00110402 in __kernel_vsyscall () from [vdso] #1 0x0076c2c9 in __read_nocancel () from /lib/libc-2.6.so #2 0x080c36a3 in _rl_init_terminal_io () from /bin/bash #3 0x080c3c23 in [unknown] from /bin/bash #4 0x080b2fb7 in rl_vi_char_search () from /bin/bash #5 0x080b3305 in rl_vi_delete () from /bin/bash #6 0x08065a11 in yyparse () from /bin/bash #7 0x08060d08 in read_secondary_line () from /bin/bash #8 0x08062f7a in read_token () from /bin/bash #9 0x08066121 in get_group_array () from /bin/bash #10 0x0805ee11 in yyerror () from /bin/bash #11 0x100bdb5f in [unknown] from Unknown #12 0x0805eeed in yyerror () from /bin/bash #13 0x0805d7d0 in main () from /bin/bash #14 0x006c0f70 in __libc_start_main () from /lib/libc-2.6.so #15 0x0805c6c1 in bind_args () from /bin/bash (fhpd) down #1 0x0076c2c9 in __read_nocancel () from /lib/libc-2.6.so (fhpd) disassemble Dump of assembler code for function: __read_nocancel 0x76c2ba <__read_nocancel+0>: push %ebx 0x76c2bb <__read_nocancel+1>: mov 0x10(%esp),%edx 0x76c2bf <__read_nocancel+5>: mov 0xc(%esp),%ecx 0x76c2c3 <__read_nocancel+9>: mov 0x8(%esp),%ebx 0x76c2c7 <__read_nocancel+d>: mov $0x3,%eax 0x76c2cc <__read_nocancel+12>: call *%gs:0x10 0x76c2d3 <__read_nocancel+19>: pop %ebx 0x76c2d4 <__read_nocancel+1a>: cmp $0xfffff001,%eax 0x76c2d9 <__read_nocancel+1f>: jae 0x76c30d 0x76c2db <__read_nocancel+21>: ret End of assembly dump (fhpd) disassemble 0x76c2c7 Dump of assembler code for function: __read_nocancel 0x76c2ba <__read_nocancel+0>: push %ebx 0x76c2bb <__read_nocancel+1>: mov 0x10(%esp),%edx 0x76c2bf <__read_nocancel+5>: mov 0xc(%esp),%ecx 0x76c2c3 <__read_nocancel+9>: mov 0x8(%esp),%ebx *0x76c2c7 <__read_nocancel+d>: mov $0x3,%eax 0x76c2cc <__read_nocancel+12>: call *%gs:0x10 0x76c2d3 <__read_nocancel+19>: pop %ebx 0x76c2d4 <__read_nocancel+1a>: cmp $0xfffff001,%eax 0x76c2d9 <__read_nocancel+1f>: jae 0x76c30d 0x76c2db <__read_nocancel+21>: ret End of assembly dump (fhpd) up #0 0x00110402 in __kernel_vsyscall () from [vdso] (fhpd) disassemble 0x76c2c7 Dump of assembler code for function: __read_nocancel 0x76c2ba <__read_nocancel+0>: push %ebx 0x76c2bb <__read_nocancel+1>: mov 0x10(%esp),%edx 0x76c2bf <__read_nocancel+5>: mov 0xc(%esp),%ecx 0x76c2c3 <__read_nocancel+9>: mov 0x8(%esp),%ebx *0x76c2c7 <__read_nocancel+d>: mov $0x3,%eax 0x76c2cc <__read_nocancel+12>: call *%gs:0x10 0x76c2d3 <__read_nocancel+19>: pop %ebx 0x76c2d4 <__read_nocancel+1a>: cmp $0xfffff001,%eax 0x76c2d9 <__read_nocancel+1f>: jae 0x76c30d 0x76c2db <__read_nocancel+21>: ret End of assembly dump (fhpd) where #0 0x00110402 in __kernel_vsyscall () from [vdso] #1 0x0076c2c9 in __read_nocancel () from /lib/libc-2.6.so #2 0x080c36a3 in _rl_init_terminal_io () from /bin/bash #3 0x080c3c23 in [unknown] from /bin/bash #4 0x080b2fb7 in rl_vi_char_search () from /bin/bash #5 0x080b3305 in rl_vi_delete () from /bin/bash #6 0x08065a11 in yyparse () from /bin/bash #7 0x08060d08 in read_secondary_line () from /bin/bash #8 0x08062f7a in read_token () from /bin/bash #9 0x08066121 in get_group_array () from /bin/bash #10 0x0805ee11 in yyerror () from /bin/bash #11 0x100bdb5f in [unknown] from Unknown #12 0x0805eeed in yyerror () from /bin/bash #13 0x0805d7d0 in main () from /bin/bash #14 0x006c0f70 in __libc_start_main () from /lib/libc-2.6.so #15 0x0805c6c1 in bind_args () from /bin/bash (fhpd) list No symbol table is available. (fhpd) down #1 0x0076c2c9 in __read_nocancel () from /lib/libc-2.6.so (fhpd) disassemble Dump of assembler code for function: __read_nocancel 0x76c2ba <__read_nocancel+0>: push %ebx 0x76c2bb <__read_nocancel+1>: mov 0x10(%esp),%edx 0x76c2bf <__read_nocancel+5>: mov 0xc(%esp),%ecx 0x76c2c3 <__read_nocancel+9>: mov 0x8(%esp),%ebx 0x76c2c7 <__read_nocancel+d>: mov $0x3,%eax 0x76c2cc <__read_nocancel+12>: call *%gs:0x10 0x76c2d3 <__read_nocancel+19>: pop %ebx 0x76c2d4 <__read_nocancel+1a>: cmp $0xfffff001,%eax 0x76c2d9 <__read_nocancel+1f>: jae 0x76c30d 0x76c2db <__read_nocancel+21>: ret End of assembly dump (fhpd) down #2 0x080c36a3 in _rl_init_terminal_io () from /bin/bash (fhpd) disassemble Dump of assembler code for function: _rl_init_terminal_io 0x80c368b <_rl_init_terminal_io+ab>: pop %ebp 0x80c368c <_rl_init_terminal_io+ac>: ret 0x80c368d <_rl_init_terminal_io+ad>: mov %esi,(%esp) 0x80c3690 <_rl_init_terminal_io+b0>: call 0x805ba6c 0x80c3695 <_rl_init_terminal_io+b5>: mov %eax,(%esp) 0x80c3698 <_rl_init_terminal_io+b8>: call 0x8067700 0x80c369d <_rl_init_terminal_io+bd>: test %eax,%eax 0x80c369f <_rl_init_terminal_io+bf>: jns 0x80c3647 0x80c36a1 <_rl_init_terminal_io+c1>: jmp 0x80c3681 *0x80c36a3 <_rl_init_terminal_io+c3>: lea 0x0(%esi),%esi 0x80c36a9 <_rl_init_terminal_io+c9>: lea 0x0(%edi),%edi 0x80c36b0 <_rl_init_terminal_io+d0>: push %ebp 0x80c36b1 <_rl_init_terminal_io+d1>: mov %esp,%ebp 0x80c36b3 <_rl_init_terminal_io+d3>: sub $0x138,%esp 0x80c36b9 <_rl_init_terminal_io+d9>: mov 0x80fcd10,%eax 0x80c36be <_rl_init_terminal_io+de>: mov %ebx,0xfffffff4(%ebp) 0x80c36c1 <_rl_init_terminal_io+e1>: lea 0xffffff6c(%ebp),%ebx 0x80c36c7 <_rl_init_terminal_io+e7>: mov %edi,0xfffffffc(%ebp) 0x80c36ca <_rl_init_terminal_io+ea>: mov %ebx,%edi 0x80c36cc <_rl_init_terminal_io+ec>: mov %esi,0xfffffff8(%ebp) End of assembly dump (fhpd) disassemble -t Dump of assembler code for function: _rl_init_terminal_io 0x80c35e0 <_rl_init_terminal_io+0>: push %ebp 0x80c35e1 <_rl_init_terminal_io+1>: mov %esp,%ebp 0x80c35e3 <_rl_init_terminal_io+3>: mov 0x8(%ebp),%eax 0x80c35e6 <_rl_init_terminal_io+6>: orl $0x20000,0x80fcd08 0x80c35f0 <_rl_init_terminal_io+10>: pop %ebp 0x80c35f1 <_rl_init_terminal_io+11>: mov %eax,0x80fcd34 0x80c35f6 <_rl_init_terminal_io+16>: xor %eax,%eax 0x80c35f8 <_rl_init_terminal_io+18>: ret 0x80c35f9 <_rl_init_terminal_io+19>: lea 0x0(%esi),%esi 0x80c3600 <_rl_init_terminal_io+20>: push %ebp 0x80c3601 <_rl_init_terminal_io+21>: xor %eax,%eax 0x80c3603 <_rl_init_terminal_io+23>: andl $0xfffdffff,0x80fcd08 0x80c360d <_rl_init_terminal_io+2d>: mov %esp,%ebp 0x80c360f <_rl_init_terminal_io+2f>: pop %ebp 0x80c3610 <_rl_init_terminal_io+30>: movl $0x0,0x80fcd34 0x80c361a <_rl_init_terminal_io+3a>: ret 0x80c361b <_rl_init_terminal_io+3b>: nop 0x80c361c <_rl_init_terminal_io+3c>: lea 0x0(%esi),%esi 0x80c3620 <_rl_init_terminal_io+40>: push %ebp 0x80c3621 <_rl_init_terminal_io+41>: mov %esp,%ebp 0x80c3623 <_rl_init_terminal_io+43>: push %esi 0x80c3624 <_rl_init_terminal_io+44>: push %ebx 0x80c3625 <_rl_init_terminal_io+45>: sub $0x20,%esp 0x80c3628 <_rl_init_terminal_io+48>: mov 0x8(%ebp),%esi 0x80c362b <_rl_init_terminal_io+4b>: lea 0xfffffff7(%ebp),%ebx 0x80c362e <_rl_init_terminal_io+4e>: jmp 0x80c3647 0x80c3630 <_rl_init_terminal_io+50>: test %eax,%eax 0x80c3632 <_rl_init_terminal_io+52>: je 0x80c3681 0x80c3634 <_rl_init_terminal_io+54>: call 0x805ba9c 0x80c3639 <_rl_init_terminal_io+59>: mov (%eax),%eax 0x80c363b <_rl_init_terminal_io+5b>: cmp $0xb,%eax 0x80c363e <_rl_init_terminal_io+5e>: xchg %ax,%ax 0x80c3640 <_rl_init_terminal_io+60>: je 0x80c368d 0x80c3642 <_rl_init_terminal_io+62>: cmp $0x4,%eax 0x80c3645 <_rl_init_terminal_io+65>: jne 0x80c3673 0x80c3647 <_rl_init_terminal_io+67>: mov %esi,(%esp) 0x80c364a <_rl_init_terminal_io+6a>: call 0x805ba6c 0x80c364f <_rl_init_terminal_io+6f>: movl $0x1,0x8(%esp) 0x80c3657 <_rl_init_terminal_io+77>: mov %ebx,0x4(%esp) 0x80c365b <_rl_init_terminal_io+7b>: mov %eax,(%esp) 0x80c365e <_rl_init_terminal_io+7e>: call 0x805bd9c 0x80c3663 <_rl_init_terminal_io+83>: cmp $0x1,%eax 0x80c3666 <_rl_init_terminal_io+86>: jne 0x80c3630 0x80c3668 <_rl_init_terminal_io+88>: movzbl 0xfffffff7(%ebp),%eax 0x80c366c <_rl_init_terminal_io+8c>: add $0x20,%esp 0x80c366f <_rl_init_terminal_io+8f>: pop %ebx 0x80c3670 <_rl_init_terminal_io+90>: pop %esi 0x80c3671 <_rl_init_terminal_io+91>: pop %ebp 0x80c3672 <_rl_init_terminal_io+92>: ret 0x80c3673 <_rl_init_terminal_io+93>: testb $0x8,0x80fcd08 0x80c367a <_rl_init_terminal_io+9a>: mov $0xfffffffe,%eax 0x80c367f <_rl_init_terminal_io+9f>: jne 0x80c3686 0x80c3681 <_rl_init_terminal_io+a1>: mov $0xffffffff,%eax 0x80c3686 <_rl_init_terminal_io+a6>: add $0x20,%esp 0x80c3689 <_rl_init_terminal_io+a9>: pop %ebx 0x80c368a <_rl_init_terminal_io+aa>: pop %esi 0x80c368b <_rl_init_terminal_io+ab>: pop %ebp 0x80c368c <_rl_init_terminal_io+ac>: ret 0x80c368d <_rl_init_terminal_io+ad>: mov %esi,(%esp) 0x80c3690 <_rl_init_terminal_io+b0>: call 0x805ba6c 0x80c3695 <_rl_init_terminal_io+b5>: mov %eax,(%esp) 0x80c3698 <_rl_init_terminal_io+b8>: call 0x8067700 0x80c369d <_rl_init_terminal_io+bd>: test %eax,%eax 0x80c369f <_rl_init_terminal_io+bf>: jns 0x80c3647 0x80c36a1 <_rl_init_terminal_io+c1>: jmp 0x80c3681 *0x80c36a3 <_rl_init_terminal_io+c3>: lea 0x0(%esi),%esi 0x80c36a9 <_rl_init_terminal_io+c9>: lea 0x0(%edi),%edi 0x80c36b0 <_rl_init_terminal_io+d0>: push %ebp 0x80c36b1 <_rl_init_terminal_io+d1>: mov %esp,%ebp 0x80c36b3 <_rl_init_terminal_io+d3>: sub $0x138,%esp 0x80c36b9 <_rl_init_terminal_io+d9>: mov 0x80fcd10,%eax 0x80c36be <_rl_init_terminal_io+de>: mov %ebx,0xfffffff4(%ebp) 0x80c36c1 <_rl_init_terminal_io+e1>: lea 0xffffff6c(%ebp),%ebx 0x80c36c7 <_rl_init_terminal_io+e7>: mov %edi,0xfffffffc(%ebp) 0x80c36ca <_rl_init_terminal_io+ea>: mov %ebx,%edi 0x80c36cc <_rl_init_terminal_io+ec>: mov %esi,0xfffffff8(%ebp) 0x80c36cf <_rl_init_terminal_io+ef>: mov %eax,(%esp) 0x80c36d2 <_rl_init_terminal_io+f2>: call 0x805ba6c 0x80c36d7 <_rl_init_terminal_io+f7>: xor %edx,%edx 0x80c36d9 <_rl_init_terminal_io+f9>: mov $0x20,%ecx 0x80c36de <_rl_init_terminal_io+fe>: mov %eax,0xfffffee0(%ebp) 0x80c36e4 <_rl_init_terminal_io+104>: mov %edx,%eax 0x80c36e6 <_rl_init_terminal_io+106>: cld 0x80c36e7 <_rl_init_terminal_io+107>: rep stos %eax,%es:(%edi) 0x80c36e9 <_rl_init_terminal_io+109>: lea 0xfffffeec(%ebp),%esi 0x80c36ef <_rl_init_terminal_io+10f>: mov $0x20,%ecx 0x80c36f4 <_rl_init_terminal_io+114>: mov %esi,%edi 0x80c36f6 <_rl_init_terminal_io+116>: cld 0x80c36f7 <_rl_init_terminal_io+117>: rep stos %eax,%es:(%edi) 0x80c36f9 <_rl_init_terminal_io+119>: mov 0xfffffee0(%ebp),%ecx 0x80c36ff <_rl_init_terminal_io+11f>: mov 0xfffffee0(%ebp),%edx 0x80c3705 <_rl_init_terminal_io+125>: shr $0x5,%ecx 0x80c3708 <_rl_init_terminal_io+128>: and $0x1f,%edx 0x80c370b <_rl_init_terminal_io+12b>: bts %edx,0xffffff6c(%ebp,%ecx,4) 0x80c3713 <_rl_init_terminal_io+133>: bts %edx,0xfffffeec(%ebp,%ecx,4) 0x80c371b <_rl_init_terminal_io+13b>: mov 0x80f9558,%edx 0x80c3721 <_rl_init_terminal_io+141>: mov 0xfffffee0(%ebp),%eax 0x80c3727 <_rl_init_terminal_io+147>: mov %esi,0xc(%esp) 0x80c372b <_rl_init_terminal_io+14b>: mov %ebx,0x4(%esp) 0x80c372f <_rl_init_terminal_io+14f>: mov %edx,0xfffffff0(%ebp) 0x80c3732 <_rl_init_terminal_io+152>: lea 0xffffffec(%ebp),%edx 0x80c3735 <_rl_init_terminal_io+155>: add $0x1,%eax 0x80c3738 <_rl_init_terminal_io+158>: movl $0x0,0xffffffec(%ebp) 0x80c373f <_rl_init_terminal_io+15f>: mov %edx,0x10(%esp) 0x80c3743 <_rl_init_terminal_io+163>: movl $0x0,0x8(%esp) 0x80c374b <_rl_init_terminal_io+16b>: mov %eax,(%esp) 0x80c374e <_rl_init_terminal_io+16e>: call 0x805c1dc 0x80c3753 <_rl_init_terminal_io+173>: mov 0xfffffff4(%ebp),%ebx 0x80c3756 <_rl_init_terminal_io+176>: mov 0xfffffff8(%ebp),%esi 0x80c3759 <_rl_init_terminal_io+179>: mov 0xfffffffc(%ebp),%edi 0x80c375c <_rl_init_terminal_io+17c>: test %eax,%eax 0x80c375e <_rl_init_terminal_io+17e>: setg %al 0x80c3761 <_rl_init_terminal_io+181>: mov %ebp,%esp 0x80c3763 <_rl_init_terminal_io+183>: pop %ebp 0x80c3764 <_rl_init_terminal_io+184>: movzbl %al,%eax 0x80c3767 <_rl_init_terminal_io+187>: ret 0x80c3768 <_rl_init_terminal_io+188>: nop 0x80c3769 <_rl_init_terminal_io+189>: lea 0x0(%esi),%esi 0x80c3770 <_rl_init_terminal_io+190>: push %ebp 0x80c3771 <_rl_init_terminal_io+191>: mov %esp,%ebp 0x80c3773 <_rl_init_terminal_io+193>: sub $0x18,%esp 0x80c3776 <_rl_init_terminal_io+196>: mov 0x8(%ebp),%eax 0x80c3779 <_rl_init_terminal_io+199>: mov %ebx,0xfffffff8(%ebp) 0x80c377c <_rl_init_terminal_io+19c>: mov %esi,0xfffffffc(%ebp) 0x80c377f <_rl_init_terminal_io+19f>: mov %eax,(%esp) 0x80c3782 <_rl_init_terminal_io+1a2>: call 0x80c3550 0x80c3787 <_rl_init_terminal_io+1a7>: mov %eax,%ebx 0x80c3789 <_rl_init_terminal_io+1a9>: call 0x80c36b0 0x80c378e <_rl_init_terminal_io+1ae>: mov %ebx,(%esp) 0x80c3791 <_rl_init_terminal_io+1b1>: mov %eax,%esi 0x80c3793 <_rl_init_terminal_io+1b3>: call 0x80c3550 0x80c3798 <_rl_init_terminal_io+1b8>: mov %esi,%eax 0x80c379a <_rl_init_terminal_io+1ba>: mov 0xfffffff8(%ebp),%ebx 0x80c379d <_rl_init_terminal_io+1bd>: mov 0xfffffffc(%ebp),%esi 0x80c37a0 <_rl_init_terminal_io+1c0>: mov %ebp,%esp 0x80c37a2 <_rl_init_terminal_io+1c2>: pop %ebp 0x80c37a3 <_rl_init_terminal_io+1c3>: ret 0x80c37a4 <_rl_init_terminal_io+1c4>: lea 0x0(%esi),%esi 0x80c37aa <_rl_init_terminal_io+1ca>: lea 0x0(%edi),%edi 0x80c37b0 <_rl_init_terminal_io+1d0>: push %ebp 0x80c37b1 <_rl_init_terminal_io+1d1>: mov %esp,%ebp 0x80c37b3 <_rl_init_terminal_io+1d3>: push %edi 0x80c37b4 <_rl_init_terminal_io+1d4>: push %esi 0x80c37b5 <_rl_init_terminal_io+1d5>: push %ebx 0x80c37b6 <_rl_init_terminal_io+1d6>: sub $0x13c,%esp 0x80c37bc <_rl_init_terminal_io+1dc>: mov 0x80fcd34,%eax 0x80c37c1 <_rl_init_terminal_io+1e1>: addl $0x1,0x80fcd28 0x80c37c8 <_rl_init_terminal_io+1e8>: test %eax,%eax 0x80c37ca <_rl_init_terminal_io+1ea>: je 0x80c37e2 0x80c37cc <_rl_init_terminal_io+1ec>: mov %eax,0xffffffec(%ebp) 0x80c37cf <_rl_init_terminal_io+1ef>: call 0x80c3600 0x80c37d4 <_rl_init_terminal_io+1f4>: mov 0xffffffec(%ebp),%eax 0x80c37d7 <_rl_init_terminal_io+1f7>: add $0x13c,%esp 0x80c37dd <_rl_init_terminal_io+1fd>: pop %ebx 0x80c37de <_rl_init_terminal_io+1fe>: pop %esi 0x80c37df <_rl_init_terminal_io+1ff>: pop %edi 0x80c37e0 <_rl_init_terminal_io+200>: pop %ebp 0x80c37e1 <_rl_init_terminal_io+201>: ret 0x80c37e2 <_rl_init_terminal_io+202>: call 0x80c3360 0x80c37e7 <_rl_init_terminal_io+207>: test %eax,%eax 0x80c37e9 <_rl_init_terminal_io+209>: jne 0x80c37d7 0x80c37eb <_rl_init_terminal_io+20b>: mov 0x80fd960,%ebx 0x80c37f1 <_rl_init_terminal_io+211>: movl $0x0,0xffffffec(%ebp) 0x80c37f8 <_rl_init_terminal_io+218>: test %ebx,%ebx 0x80c37fa <_rl_init_terminal_io+21a>: je 0x80c3a35 0x80c3800 <_rl_init_terminal_io+220>: lea 0xffffffec(%ebp),%eax 0x80c3803 <_rl_init_terminal_io+223>: call 0x80c34a0 0x80c3808 <_rl_init_terminal_io+228>: test %eax,%eax 0x80c380a <_rl_init_terminal_io+22a>: mov %eax,%esi 0x80c380c <_rl_init_terminal_io+22c>: jne 0x80c37d4 0x80c380e <_rl_init_terminal_io+22e>: call *0x80fd960 0x80c3814 <_rl_init_terminal_io+234>: mov 0x80fe764,%ecx 0x80c381a <_rl_init_terminal_io+23a>: test %ecx,%ecx 0x80c381c <_rl_init_terminal_io+23c>: jne 0x80c3a2b 0x80c3822 <_rl_init_terminal_io+242>: mov 0x80fcd10,%eax 0x80c3827 <_rl_init_terminal_io+247>: lea 0xffffff60(%ebp),%ebx 0x80c382d <_rl_init_terminal_io+24d>: movl $0x0,0xffffffe8(%ebp) 0x80c3834 <_rl_init_terminal_io+254>: mov %ebx,%edi 0x80c3836 <_rl_init_terminal_io+256>: mov %eax,(%esp) 0x80c3839 <_rl_init_terminal_io+259>: call 0x805ba6c 0x80c383e <_rl_init_terminal_io+25e>: mov $0x20,%ecx 0x80c3843 <_rl_init_terminal_io+263>: mov %eax,0xfffffed0(%ebp) 0x80c3849 <_rl_init_terminal_io+269>: mov %esi,%eax 0x80c384b <_rl_init_terminal_io+26b>: cld 0x80c384c <_rl_init_terminal_io+26c>: rep stos %eax,%es:(%edi) 0x80c384e <_rl_init_terminal_io+26e>: lea 0xfffffee0(%ebp),%edi 0x80c3854 <_rl_init_terminal_io+274>: mov $0x20,%ecx 0x80c3859 <_rl_init_terminal_io+279>: mov %edi,0xfffffecc(%ebp) 0x80c385f <_rl_init_terminal_io+27f>: cld 0x80c3860 <_rl_init_terminal_io+280>: rep stos %eax,%es:(%edi) 0x80c3862 <_rl_init_terminal_io+282>: mov 0xfffffed0(%ebp),%edx 0x80c3868 <_rl_init_terminal_io+288>: mov 0xfffffed0(%ebp),%eax 0x80c386e <_rl_init_terminal_io+28e>: shr $0x5,%edx 0x80c3871 <_rl_init_terminal_io+291>: and $0x1f,%eax 0x80c3874 <_rl_init_terminal_io+294>: bts %eax,0xffffff60(%ebp,%edx,4) 0x80c387c <_rl_init_terminal_io+29c>: bts %eax,0xfffffee0(%ebp,%edx,4) 0x80c3884 <_rl_init_terminal_io+2a4>: mov 0x80f9558,%eax 0x80c3889 <_rl_init_terminal_io+2a9>: movl $0x0,0xffffffe0(%ebp) 0x80c3890 <_rl_init_terminal_io+2b0>: movl $0x0,0x8(%esp) 0x80c3898 <_rl_init_terminal_io+2b8>: mov %ebx,0x4(%esp) 0x80c389c <_rl_init_terminal_io+2bc>: mov %eax,0xffffffe4(%ebp) 0x80c389f <_rl_init_terminal_io+2bf>: lea 0xffffffe0(%ebp),%eax 0x80c38a2 <_rl_init_terminal_io+2c2>: mov %eax,0x10(%esp) 0x80c38a6 <_rl_init_terminal_io+2c6>: lea 0xfffffee0(%ebp),%eax 0x80c38ac <_rl_init_terminal_io+2cc>: mov %eax,0xc(%esp) 0x80c38b0 <_rl_init_terminal_io+2d0>: mov 0xfffffed0(%ebp),%eax 0x80c38b6 <_rl_init_terminal_io+2d6>: add $0x1,%eax 0x80c38b9 <_rl_init_terminal_io+2d9>: mov %eax,(%esp) 0x80c38bc <_rl_init_terminal_io+2dc>: call 0x805c1dc 0x80c38c1 <_rl_init_terminal_io+2e1>: test %eax,%eax 0x80c38c3 <_rl_init_terminal_io+2e3>: jle 0x80c3957 0x80c38c9 <_rl_init_terminal_io+2e9>: call 0x805ba9c 0x80c38ce <_rl_init_terminal_io+2ee>: mov 0xfffffed0(%ebp),%ecx 0x80c38d4 <_rl_init_terminal_io+2f4>: movl $0x0,(%eax) 0x80c38da <_rl_init_terminal_io+2fa>: mov %eax,%ebx 0x80c38dc <_rl_init_terminal_io+2fc>: lea 0xffffffe8(%ebp),%eax 0x80c38df <_rl_init_terminal_io+2ff>: mov %eax,0x8(%esp) 0x80c38e3 <_rl_init_terminal_io+303>: movl $0x541b,0x4(%esp) 0x80c38eb <_rl_init_terminal_io+30b>: mov %ecx,(%esp) 0x80c38ee <_rl_init_terminal_io+30e>: call 0x805bf0c 0x80c38f3 <_rl_init_terminal_io+313>: cmp $0xffffffff,%eax 0x80c38f6 <_rl_init_terminal_io+316>: mov %eax,%esi 0x80c38f8 <_rl_init_terminal_io+318>: je 0x80c3970 0x80c38fa <_rl_init_terminal_io+31a>: mov 0xffffffe8(%ebp),%ebx 0x80c38fd <_rl_init_terminal_io+31d>: test %ebx,%ebx 0x80c38ff <_rl_init_terminal_io+31f>: jle 0x80c3957 0x80c3901 <_rl_init_terminal_io+321>: call 0x80c3470 0x80c3906 <_rl_init_terminal_io+326>: cmp %eax,%ebx 0x80c3908 <_rl_init_terminal_io+328>: jle 0x80c390d 0x80c390a <_rl_init_terminal_io+32a>: mov %eax,0xffffffe8(%ebp) 0x80c390d <_rl_init_terminal_io+32d>: cmp $0x1fe,%eax 0x80c3912 <_rl_init_terminal_io+332>: setle %al 0x80c3915 <_rl_init_terminal_io+335>: movzbl %al,%eax 0x80c3918 <_rl_init_terminal_io+338>: sub $0x1,%eax 0x80c391b <_rl_init_terminal_io+33b>: and %eax,0xffffffe8(%ebp) 0x80c391e <_rl_init_terminal_io+33e>: add $0x1,%esi 0x80c3921 <_rl_init_terminal_io+341>: je 0x80c3a05 0x80c3927 <_rl_init_terminal_io+347>: mov 0xffffffe8(%ebp),%eax 0x80c392a <_rl_init_terminal_io+34a>: sub $0x1,%eax 0x80c392d <_rl_init_terminal_io+34d>: mov %eax,0xffffffe8(%ebp) 0x80c3930 <_rl_init_terminal_io+350>: add $0x1,%eax 0x80c3933 <_rl_init_terminal_io+353>: je 0x80c3957 0x80c3935 <_rl_init_terminal_io+355>: mov 0x80fcd10,%eax 0x80c393a <_rl_init_terminal_io+35a>: mov %eax,(%esp) 0x80c393d <_rl_init_terminal_io+35d>: call *0x80f9554 0x80c3943 <_rl_init_terminal_io+363>: mov %eax,%ebx 0x80c3945 <_rl_init_terminal_io+365>: mov %eax,(%esp) 0x80c3948 <_rl_init_terminal_io+368>: call 0x80c3570 0x80c394d <_rl_init_terminal_io+36d>: cmp $0xa,%ebx 0x80c3950 <_rl_init_terminal_io+370>: je 0x80c3957 0x80c3952 <_rl_init_terminal_io+372>: cmp $0xd,%ebx 0x80c3955 <_rl_init_terminal_io+375>: jne 0x80c3927 0x80c3957 <_rl_init_terminal_io+377>: mov 0x80fd960,%eax 0x80c395c <_rl_init_terminal_io+37c>: test %eax,%eax 0x80c395e <_rl_init_terminal_io+37e>: jne 0x80c3800 0x80c3964 <_rl_init_terminal_io+384>: jmp 0x80c37d4 0x80c3969 <_rl_init_terminal_io+389>: lea 0x0(%esi),%esi 0x80c3970 <_rl_init_terminal_io+390>: cmpl $0x5,(%ebx) 0x80c3973 <_rl_init_terminal_io+393>: je 0x80c3a21 0x80c3979 <_rl_init_terminal_io+399>: mov 0xfffffed0(%ebp),%edi 0x80c397f <_rl_init_terminal_io+39f>: movl $0x0,0x8(%esp) 0x80c3987 <_rl_init_terminal_io+3a7>: movl $0x3,0x4(%esp) 0x80c398f <_rl_init_terminal_io+3af>: mov %edi,(%esp) 0x80c3992 <_rl_init_terminal_io+3b2>: call 0x805c46c 0x80c3997 <_rl_init_terminal_io+3b7>: movl $0x4,0x4(%esp) 0x80c399f <_rl_init_terminal_io+3bf>: mov %edi,(%esp) 0x80c39a2 <_rl_init_terminal_io+3c2>: mov %eax,%ebx 0x80c39a4 <_rl_init_terminal_io+3c4>: or $0x8,%ah 0x80c39a7 <_rl_init_terminal_io+3c7>: mov %eax,0x8(%esp) 0x80c39ab <_rl_init_terminal_io+3cb>: call 0x805c46c 0x80c39b0 <_rl_init_terminal_io+3d0>: lea 0xfffffff3(%ebp),%eax 0x80c39b3 <_rl_init_terminal_io+3d3>: movl $0x1,0x8(%esp) 0x80c39bb <_rl_init_terminal_io+3db>: mov %eax,0x4(%esp) 0x80c39bf <_rl_init_terminal_io+3df>: mov %edi,(%esp) 0x80c39c2 <_rl_init_terminal_io+3e2>: call 0x805bd9c 0x80c39c7 <_rl_init_terminal_io+3e7>: mov %ebx,0x8(%esp) 0x80c39cb <_rl_init_terminal_io+3eb>: movl $0x4,0x4(%esp) 0x80c39d3 <_rl_init_terminal_io+3f3>: mov %edi,(%esp) 0x80c39d6 <_rl_init_terminal_io+3f6>: mov %eax,0xffffffe8(%ebp) 0x80c39d9 <_rl_init_terminal_io+3f9>: call 0x805c46c 0x80c39de <_rl_init_terminal_io+3fe>: mov 0xffffffe8(%ebp),%ebx 0x80c39e1 <_rl_init_terminal_io+401>: cmp $0xffffffff,%ebx 0x80c39e4 <_rl_init_terminal_io+404>: je 0x80c3957 0x80c39ea <_rl_init_terminal_io+40a>: test %ebx,%ebx 0x80c39ec <_rl_init_terminal_io+40c>: jne 0x80c38fd 0x80c39f2 <_rl_init_terminal_io+412>: movl $0xffffffff,(%esp) 0x80c39f9 <_rl_init_terminal_io+419>: call 0x80c3570 0x80c39fe <_rl_init_terminal_io+41e>: xchg %ax,%ax 0x80c3a00 <_rl_init_terminal_io+420>: jmp 0x80c3957 0x80c3a05 <_rl_init_terminal_io+425>: mov 0xffffffe8(%ebp),%edx 0x80c3a08 <_rl_init_terminal_io+428>: test %edx,%edx 0x80c3a0a <_rl_init_terminal_io+42a>: je 0x80c3957 0x80c3a10 <_rl_init_terminal_io+430>: movsbl 0xfffffff3(%ebp),%eax 0x80c3a14 <_rl_init_terminal_io+434>: mov %eax,(%esp) 0x80c3a17 <_rl_init_terminal_io+437>: call 0x80c3570 0x80c3a1c <_rl_init_terminal_io+43c>: jmp 0x80c3957 0x80c3a21 <_rl_init_terminal_io+441>: movl $0x1,0x80fe764 0x80c3a2b <_rl_init_terminal_io+44b>: mov $0xa,%eax 0x80c3a30 <_rl_init_terminal_io+450>: jmp 0x80c37d7 0x80c3a35 <_rl_init_terminal_io+455>: lea 0xffffffec(%ebp),%eax 0x80c3a38 <_rl_init_terminal_io+458>: call 0x80c34a0 0x80c3a3d <_rl_init_terminal_io+45d>: test %eax,%eax 0x80c3a3f <_rl_init_terminal_io+45f>: jne 0x80c37d4 0x80c3a45 <_rl_init_terminal_io+465>: mov 0x80fcd10,%eax 0x80c3a4a <_rl_init_terminal_io+46a>: mov %eax,(%esp) 0x80c3a4d <_rl_init_terminal_io+46d>: call *0x80f9554 0x80c3a53 <_rl_init_terminal_io+473>: mov %eax,0xffffffec(%ebp) 0x80c3a56 <_rl_init_terminal_io+476>: jmp 0x80c37d4 0x80c3a5b <_rl_init_terminal_io+47b>: nop End of assembly dump (fhpd) list No symbol table is available. (fhpd) disassemble Dump of assembler code for function: _rl_init_terminal_io 0x80c368b <_rl_init_terminal_io+ab>: pop %ebp 0x80c368c <_rl_init_terminal_io+ac>: ret 0x80c368d <_rl_init_terminal_io+ad>: mov %esi,(%esp) 0x80c3690 <_rl_init_terminal_io+b0>: call 0x805ba6c 0x80c3695 <_rl_init_terminal_io+b5>: mov %eax,(%esp) 0x80c3698 <_rl_init_terminal_io+b8>: call 0x8067700 0x80c369d <_rl_init_terminal_io+bd>: test %eax,%eax 0x80c369f <_rl_init_terminal_io+bf>: jns 0x80c3647 0x80c36a1 <_rl_init_terminal_io+c1>: jmp 0x80c3681 *0x80c36a3 <_rl_init_terminal_io+c3>: lea 0x0(%esi),%esi 0x80c36a9 <_rl_init_terminal_io+c9>: lea 0x0(%edi),%edi 0x80c36b0 <_rl_init_terminal_io+d0>: push %ebp 0x80c36b1 <_rl_init_terminal_io+d1>: mov %esp,%ebp 0x80c36b3 <_rl_init_terminal_io+d3>: sub $0x138,%esp 0x80c36b9 <_rl_init_terminal_io+d9>: mov 0x80fcd10,%eax 0x80c36be <_rl_init_terminal_io+de>: mov %ebx,0xfffffff4(%ebp) 0x80c36c1 <_rl_init_terminal_io+e1>: lea 0xffffff6c(%ebp),%ebx 0x80c36c7 <_rl_init_terminal_io+e7>: mov %edi,0xfffffffc(%ebp) 0x80c36ca <_rl_init_terminal_io+ea>: mov %ebx,%edi 0x80c36cc <_rl_init_terminal_io+ec>: mov %esi,0xfffffff8(%ebp) End of assembly dump (fhpd) quit Quitting... ---------------------------------------------------------------------------- [... now show that you can create a core file from a running process and then use that core file with fhpd ...] ---------------------------------------------------------------------------- $ ./frysk-core/frysk/bindir/fcore 2072 $ ./frysk-core/frysk/bindir/fhpd core.2072 Attached to core file: /home/mark/src/frysk-obj/core.2072 (fhpd) where #0 0x00110402 in __kernel_vsyscall () from #1 0x0076c2c9 in __read_nocancel () from /lib/libc.so.6 #2 0x080c36a3 in _rl_init_terminal_io () from /bin/bash #3 0x080c3c23 in [unknown] from /bin/bash #4 0x080b2fb7 in rl_vi_char_search () from /bin/bash #5 0x080b3305 in rl_vi_delete () from /bin/bash #6 0x08065a11 in yyparse () from /bin/bash #7 0x08060d08 in read_secondary_line () from /bin/bash #8 0x08062f7a in read_token () from /bin/bash #9 0x08066121 in get_group_array () from /bin/bash #10 0x0805ee11 in yyerror () from /bin/bash #11 0x100bdb5f in [unknown] from Unknown #12 0x0805eeed in yyerror () from /bin/bash #13 0x0805d7d0 in main () from /bin/bash #14 0x006c0f70 in __libc_start_main () from /lib/libc.so.6 #15 0x0805c6c1 in bind_args () from /bin/bash (fhpd) down #1 0x0076c2c9 in __read_nocancel () from /lib/libc.so.6 (fhpd) dissassmeble Error: Unrecognized command: dissassmeble. (fhpd) disassemble Dump of assembler code for function: __read_nocancel 0x76c2ba <__read_nocancel+0>: push %ebx 0x76c2bb <__read_nocancel+1>: mov 0x10(%esp),%edx 0x76c2bf <__read_nocancel+5>: mov 0xc(%esp),%ecx 0x76c2c3 <__read_nocancel+9>: mov 0x8(%esp),%ebx 0x76c2c7 <__read_nocancel+d>: mov $0x3,%eax 0x76c2cc <__read_nocancel+12>: call *%gs:0x10 0x76c2d3 <__read_nocancel+19>: pop %ebx 0x76c2d4 <__read_nocancel+1a>: cmp $0xfffff001,%eax 0x76c2d9 <__read_nocancel+1f>: jae 0x76c30d 0x76c2db <__read_nocancel+21>: ret End of assembly dump (fhpd) regs eax: -512 ebx: 0 ecx: -1075342433 edx: 1 esi: 156801632 edi: 156801632 ebp: -1075342424 eip: 7783123 eflags: 2097734 esp: -1075342472 (fhpd) down #2 0x080c36a3 in _rl_init_terminal_io () from /bin/bash (fhpd) disassemble Dump of assembler code for function: _rl_init_terminal_io 0x80c368b <_rl_init_terminal_io+ab>: pop %ebp 0x80c368c <_rl_init_terminal_io+ac>: ret 0x80c368d <_rl_init_terminal_io+ad>: mov %esi,(%esp) 0x80c3690 <_rl_init_terminal_io+b0>: call 0x805ba6c 0x80c3695 <_rl_init_terminal_io+b5>: mov %eax,(%esp) 0x80c3698 <_rl_init_terminal_io+b8>: call 0x8067700 0x80c369d <_rl_init_terminal_io+bd>: test %eax,%eax 0x80c369f <_rl_init_terminal_io+bf>: jns 0x80c3647 0x80c36a1 <_rl_init_terminal_io+c1>: jmp 0x80c3681 *0x80c36a3 <_rl_init_terminal_io+c3>: lea 0x0(%esi),%esi 0x80c36a9 <_rl_init_terminal_io+c9>: lea 0x0(%edi),%edi 0x80c36b0 <_rl_init_terminal_io+d0>: push %ebp 0x80c36b1 <_rl_init_terminal_io+d1>: mov %esp,%ebp 0x80c36b3 <_rl_init_terminal_io+d3>: sub $0x138,%esp 0x80c36b9 <_rl_init_terminal_io+d9>: mov 0x80fcd10,%eax 0x80c36be <_rl_init_terminal_io+de>: mov %ebx,0xfffffff4(%ebp) 0x80c36c1 <_rl_init_terminal_io+e1>: lea 0xffffff6c(%ebp),%ebx 0x80c36c7 <_rl_init_terminal_io+e7>: mov %edi,0xfffffffc(%ebp) 0x80c36ca <_rl_init_terminal_io+ea>: mov %ebx,%edi 0x80c36cc <_rl_init_terminal_io+ec>: mov %esi,0xfffffff8(%ebp) End of assembly dump (fhpd) list No symbol table is available. (fhpd) down #3 0x080c3c23 in [unknown] from /bin/bash (fhpd) down #4 0x080b2fb7 in rl_vi_char_search () from /bin/bash (fhpd) disassemble Dump of assembler code for function: rl_vi_char_search 0x80b2f9a : je 0x80b2ff1 0x80b2f9c : cmp $0xffffffff,%edx 0x80b2f9f : nop 0x80b2fa0 : je 0x80b2ff9 0x80b2fa2 : mov 0x80f6c24,%eax 0x80b2fa7 : mov %edx,0x80fcd64 0x80b2fad : mov %eax,0x4(%esp) 0x80b2fb1 : movzbl %dl,%eax 0x80b2fb4 : mov %eax,(%esp) *0x80b2fb7 : call 0x80b2c80 0x80b2fbc : mov 0x80fcd34,%edx 0x80b2fc2 : test %edx,%edx 0x80b2fc4 : je 0x80b2fd0 0x80b2fc6 : call 0x80b2e60 0x80b2fcb : xor %eax,%eax 0x80b2fcd : leave 0x80b2fce : ret 0x80b2fcf : nop 0x80b2fd0 : mov 0xfffffffc(%ebp),%eax 0x80b2fd3 : cmp 0x80fcd00,%eax End of assembly dump (fhpd) disassemble -t Dump of assembler code for function: rl_vi_char_search 0x80b2ee0 : add %al,(%eax) 0x80b2ee2 : movl $0xa,0x4(%esp) 0x80b2eea : movl $0x1,(%esp) 0x80b2ef1 : call 0x80c5860 0x80b2ef6 : jmp 0x80b2e90 0x80b2ef8 : mov 0x80fe780,%eax 0x80b2efd : test %eax,%eax 0x80b2eff : jne 0x80b2eb7 0x80b2f01 : mov 0x80fe784,%eax 0x80b2f06 : test %eax,%eax 0x80b2f08 : jne 0x80b2eb7 0x80b2f0a : leave 0x80b2f0b : jmp 0x80bdce0 0x80b2f10 : call 0x80b3c00 0x80b2f15 : jmp 0x80b2e7f 0x80b2f1a : lea 0x0(%esi),%esi 0x80b2f20 : push %ebp 0x80b2f21 : mov %esp,%ebp 0x80b2f23 : sub $0x18,%esp 0x80b2f26 : mov 0x80fcd00,%eax 0x80b2f2b : movl $0xffffffff,0x80fcd64 0x80b2f35 : movl $0x0,0x80fcd60 0x80b2f3f : mov %eax,0xfffffffc(%ebp) 0x80b2f42 : movl $0x1,0x4(%esp) 0x80b2f4a : movl $0x80fe6c0,(%esp) 0x80b2f51 : call 0x805c61c 0x80b2f56 : test %eax,%eax 0x80b2f58 : jne 0x80b3020 0x80b2f5e : mov 0x80fcd34,%eax 0x80b2f63 : test %eax,%eax 0x80b2f65 : je 0x80b3048 0x80b2f6b : orl $0x8,0x80fcd08 0x80b2f72 : call 0x80c37b0 0x80b2f77 : mov %eax,%edx 0x80b2f79 : mov 0x80fcd08,%eax 0x80b2f7e : and $0xfffffff7,%eax 0x80b2f81 : cmp $0xfffffffe,%edx 0x80b2f84 : mov %eax,0x80fcd08 0x80b2f89 : je 0x80b3003 0x80b2f8b : cmp $0xffffffff,%edx 0x80b2f8e : je 0x80b3060 0x80b2f94 : cmp 0x80f6c38,%edx 0x80b2f9a : je 0x80b2ff1 0x80b2f9c : cmp $0xffffffff,%edx 0x80b2f9f : nop 0x80b2fa0 : je 0x80b2ff9 0x80b2fa2 : mov 0x80f6c24,%eax 0x80b2fa7 : mov %edx,0x80fcd64 0x80b2fad : mov %eax,0x4(%esp) 0x80b2fb1 : movzbl %dl,%eax 0x80b2fb4 : mov %eax,(%esp) *0x80b2fb7 : call 0x80b2c80 0x80b2fbc : mov 0x80fcd34,%edx 0x80b2fc2 : test %edx,%edx 0x80b2fc4 : je 0x80b2fd0 0x80b2fc6 : call 0x80b2e60 0x80b2fcb : xor %eax,%eax 0x80b2fcd : leave 0x80b2fce : ret 0x80b2fcf : nop 0x80b2fd0 : mov 0xfffffffc(%ebp),%eax 0x80b2fd3 : cmp 0x80fcd00,%eax 0x80b2fd9 : sete %al 0x80b2fdc : movzbl %al,%eax 0x80b2fdf : sub $0x1,%eax 0x80b2fe2 : and %eax,0x80fcd00 0x80b2fe8 : call 0x80b2e60 0x80b2fed : xor %eax,%eax 0x80b2fef : jmp 0x80b2fcd 0x80b2ff1 : cmp 0x80fcd64,%edx 0x80b2ff7 : je 0x80b2f9c 0x80b2ff9 : mov 0x80fe784,%ecx 0x80b2fff : test %ecx,%ecx 0x80b3001 : jne 0x80b2fa2 0x80b3003 : or $0x800000,%eax 0x80b3008 : mov %eax,0x80fcd08 0x80b300d : mov $0x1,%eax 0x80b3012 : movl $0x1,0x80fe764 0x80b301c : leave 0x80b301d : ret 0x80b301e : xchg %ax,%ax 0x80b3020 : call *0x80f953c 0x80b3026 : xor %eax,%eax 0x80b3028 : testb $0x8,0x80fcd0a 0x80b302f : movl $0x0,0x80fd1c8 End of assembly dump (fhpd) disassemble -help disassemble [OPTIONS] [startAddress] || disassemble [-OPTIONS] disassemble Options: -i, -instructions-only only print the instruction portion not the parameters -t, -no-truncate don't truncate the number of instructions printed -s, -no-symbol don't print the symbol name Standard Options: -help print this help disassemble the function surrounding the current pc, the function surrounding a given address, or a range of functions. (fhpd) regs eax: -512 ebx: 0 ecx: -1075342433 edx: 1 esi: 1 edi: 156801632 ebp: -1075342056 eip: 134950775 eflags: 2097734 esp: -1075342080 (fhpd) print Usage: print expression [-name] [-index] [-format d|o|x] (fhpd) print 134950775 -format x 0x80b2f77 (fhpd) disassemble 0x80b2f77 Dump of assembler code for function: rl_vi_char_search 0x80b2f4a : movl $0x80fe6c0,(%esp) 0x80b2f51 : call 0x805c61c 0x80b2f56 : test %eax,%eax 0x80b2f58 : jne 0x80b3020 0x80b2f5e : mov 0x80fcd34,%eax 0x80b2f63 : test %eax,%eax 0x80b2f65 : je 0x80b3048 0x80b2f6b : orl $0x8,0x80fcd08 0x80b2f72 : call 0x80c37b0 *0x80b2f77 : mov %eax,%edx 0x80b2f79 : mov 0x80fcd08,%eax 0x80b2f7e : and $0xfffffff7,%eax 0x80b2f81 : cmp $0xfffffffe,%edx 0x80b2f84 : mov %eax,0x80fcd08 0x80b2f89 : je 0x80b3003 0x80b2f8b : cmp $0xffffffff,%edx 0x80b2f8e : je 0x80b3060 0x80b2f94 : cmp 0x80f6c38,%edx 0x80b2f9a : je 0x80b2ff1 0x80b2f9c : cmp $0xffffffff,%edx End of assembly dump (fhpd) disassemble 134950775 Dump of assembler code for function: rl_vi_char_search 0x80b2f4a : movl $0x80fe6c0,(%esp) 0x80b2f51 : call 0x805c61c 0x80b2f56 : test %eax,%eax 0x80b2f58 : jne 0x80b3020 0x80b2f5e : mov 0x80fcd34,%eax 0x80b2f63 : test %eax,%eax 0x80b2f65 : je 0x80b3048 0x80b2f6b : orl $0x8,0x80fcd08 0x80b2f72 : call 0x80c37b0 *0x80b2f77 : mov %eax,%edx 0x80b2f79 : mov 0x80fcd08,%eax 0x80b2f7e : and $0xfffffff7,%eax 0x80b2f81 : cmp $0xfffffffe,%edx 0x80b2f84 : mov %eax,0x80fcd08 0x80b2f89 : je 0x80b3003 0x80b2f8b : cmp $0xffffffff,%edx 0x80b2f8e : je 0x80b3060 0x80b2f94 : cmp 0x80f6c38,%edx 0x80b2f9a : je 0x80b2ff1 0x80b2f9c : cmp $0xffffffff,%edx End of assembly dump (fhpd) disassemble main java.lang.NullPointerException at frysk.debuginfo.DebugInfoEvaluator.getDie(fhpd) at frysk.debuginfo.DebugInfoEvaluator.get(fhpd) at frysk.expr.CppTreeParser.expr(fhpd) at frysk.expr.CppTreeParser.expr(fhpd) at frysk.debuginfo.DebugInfo.print(fhpd) at frysk.hpd.CLI.parseValue(fhpd) at frysk.hpd.DisassembleCommand.handle(fhpd) at frysk.hpd.CLI.execCommand(fhpd) at frysk.bindir.fhpd.main(fhpd) Internal debugger error: (fhpd) print main java.lang.NullPointerException at frysk.debuginfo.DebugInfoEvaluator.getDie(fhpd) at frysk.debuginfo.DebugInfoEvaluator.get(fhpd) at frysk.expr.CppTreeParser.expr(fhpd) at frysk.expr.CppTreeParser.expr(fhpd) at frysk.debuginfo.DebugInfo.print(fhpd) at frysk.hpd.CLI.parseValue(fhpd) at frysk.hpd.PrintCommand.handle(fhpd) at frysk.hpd.CLI.execCommand(fhpd) at frysk.bindir.fhpd.main(fhpd) Internal debugger error: (fhpd) what main Error: main not found in scope. (fhpd) detach (fhpd) attach 2072 Attached to process 2072 (fhpd) what main Error: No symbol table is available. (fhpd) quit Quitting... [mark@hermans frysk-obj]$ ./frysk-core/frysk/bindir/fhpd 2072 Attached to process 2072 (fhpd) where #0 0x00110402 in __kernel_vsyscall () from [vdso] #1 0x0076c2c9 in __read_nocancel () from /lib/libc-2.6.so #2 0x080c36a3 in _rl_init_terminal_io () from /bin/bash #3 0x080c3c23 in [unknown] from /bin/bash #4 0x080b2fb7 in rl_vi_char_search () from /bin/bash #5 0x080b3305 in rl_vi_delete () from /bin/bash #6 0x08065a11 in yyparse () from /bin/bash #7 0x08060d08 in read_secondary_line () from /bin/bash #8 0x08062f7a in read_token () from /bin/bash #9 0x08066121 in get_group_array () from /bin/bash #10 0x0805ee11 in yyerror () from /bin/bash #11 0x100bdb5f in [unknown] from Unknown #12 0x0805eeed in yyerror () from /bin/bash #13 0x0805d7d0 in main () from /bin/bash #14 0x006c0f70 in __libc_start_main () from /lib/libc-2.6.so #15 0x0805c6c1 in bind_args () from /bin/bash (fhpd) what main Error: No symbol table is available. (fhpd) print main Error: Variable main not found in scope (fhpd) down #1 0x0076c2c9 in __read_nocancel () from /lib/libc-2.6.so (fhpd) down #2 0x080c36a3 in _rl_init_terminal_io () from /bin/bash (fhpd) down #3 0x080c3c23 in [unknown] from /bin/bash (fhpd) down #4 0x080b2fb7 in rl_vi_char_search () from /bin/bash (fhpd) down #5 0x080b3305 in rl_vi_delete () from /bin/bash (fhpd) down -help Usage: down [num-levels] (fhpd) down 8 #13 0x0805d7d0 in main () from /bin/bash (fhpd) print main Aborted [mark@hermans frysk-obj]$ ./frysk-core/frysk/bindir/fhpd 2072 Attached to process 2072 (fhpd) where #0 0x00110402 in __kernel_vsyscall () from [vdso] #1 0x0076c2c9 in __read_nocancel () from /lib/libc-2.6.so #2 0x080c36a3 in _rl_init_terminal_io () from /bin/bash #3 0x080c3c23 in [unknown] from /bin/bash #4 0x080b2fb7 in rl_vi_char_search () from /bin/bash #5 0x080b3305 in rl_vi_delete () from /bin/bash #6 0x08065a11 in yyparse () from /bin/bash #7 0x08060d08 in read_secondary_line () from /bin/bash #8 0x08062f7a in read_token () from /bin/bash #9 0x08066121 in get_group_array () from /bin/bash #10 0x0805ee11 in yyerror () from /bin/bash #11 0x100bdb5f in [unknown] from Unknown #12 0x0805eeed in yyerror () from /bin/bash #13 0x0805d7d0 in main () from /bin/bash #14 0x006c0f70 in __libc_start_main () from /lib/libc-2.6.so #15 0x0805c6c1 in bind_args () from /bin/bash (fhpd) disassemble 0x80c36a3 Dump of assembler code for function: _rl_init_terminal_io 0x80c368b <_rl_init_terminal_io+ab>: pop %ebp 0x80c368c <_rl_init_terminal_io+ac>: ret 0x80c368d <_rl_init_terminal_io+ad>: mov %esi,(%esp) 0x80c3690 <_rl_init_terminal_io+b0>: call 0x805ba6c 0x80c3695 <_rl_init_terminal_io+b5>: mov %eax,(%esp) 0x80c3698 <_rl_init_terminal_io+b8>: call 0x8067700 0x80c369d <_rl_init_terminal_io+bd>: test %eax,%eax 0x80c369f <_rl_init_terminal_io+bf>: jns 0x80c3647 0x80c36a1 <_rl_init_terminal_io+c1>: jmp 0x80c3681 *0x80c36a3 <_rl_init_terminal_io+c3>: lea 0x0(%esi),%esi 0x80c36a9 <_rl_init_terminal_io+c9>: lea 0x0(%edi),%edi 0x80c36b0 <_rl_init_terminal_io+d0>: push %ebp 0x80c36b1 <_rl_init_terminal_io+d1>: mov %esp,%ebp 0x80c36b3 <_rl_init_terminal_io+d3>: sub $0x138,%esp 0x80c36b9 <_rl_init_terminal_io+d9>: mov 0x80fcd10,%eax 0x80c36be <_rl_init_terminal_io+de>: mov %ebx,0xfffffff4(%ebp) 0x80c36c1 <_rl_init_terminal_io+e1>: lea 0xffffff6c(%ebp),%ebx 0x80c36c7 <_rl_init_terminal_io+e7>: mov %edi,0xfffffffc(%ebp) 0x80c36ca <_rl_init_terminal_io+ea>: mov %ebx,%edi 0x80c36cc <_rl_init_terminal_io+ec>: mov %esi,0xfffffff8(%ebp) End of assembly dump (fhpd) disassemble -help disassemble [OPTIONS] [startAddress] || disassemble [-OPTIONS] disassemble Options: -i, -instructions-only only print the instruction portion not the parameters -t, -no-truncate don't truncate the number of instructions printed -s, -no-symbol don't print the symbol name Standard Options: -help print this help disassemble the function surrounding the current pc, the function surrounding a given address, or a range of functions. (fhpd) help disassemble disassemble [OPTIONS] [startAddress] || disassemble [-OPTIONS] disassemble the function surrounding the current pc, the function surrounding a given address, or a range of functions. (fhpd) quit Quitting... From mark@klomp.org Mon Aug 6 15:34:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 06 Aug 2007 15:34:00 -0000 Subject: test mercurial repository (Was: frysk meeting 2007-08-01) In-Reply-To: <46B04E06.7060102@redhat.com> References: <46AF3DBE.1020802@redhat.com> <46AF7C3A.90509@redhat.com> <46B04E06.7060102@redhat.com> Message-ID: <1186414438.3766.72.camel@dijkstra.wildebeest.org> On Wed, 2007-08-01 at 11:10 +0200, Tim Moore wrote: > Andrew Cagney wrote: > > + discuss switching to git and/or mercurial > > > As further grist for the mill, and hopefully not gasoline on the fire, here is our > colleague Jim Meyering's view on git vs. hg: http://meyering.net/dVCS/ . He's > even more adamant about it in person :) This discussion and my own struggles this weekend to get a mirror of the repository into mercurial show how fragile all these distributed version control systems still are :( Anyway, Tim gave a great hint about how he got the git mirror working. He reconstructed the original repository by checking in symbolic links to restore to original repo/modules splitup as in CVS. Then I thought you could also try to do this beforehand on the raw CVS repository. And yes, that works pretty well to make tailor grok it all. Tailor is nice since it can translate between all kinds of different version control systems: http://wiki.darcs.net/DarcsWiki/Tailor Attached is the script I use to get at the raw CVS repository, patch it up a little to appease tailor and the tailor config file. This only gives the main branch, no branches, but it does include all 6100+ changesets since 2005 (6103 changesets with 37342 changes to 9481 files). It also makes frysk look like just one big module. But I don't know if anybody ever actually uses the separate frysk-* and frysk*-build modules in the first place. The first conversion is super slow (multiple hours!) this seems to come from CVS having a "limiter" that only allows one transaction each second. And with 6000+ changesets and different files in a changeset not being part of the same transaction according to CVS, you quickly get to 5 hours just waiting for CVS... Unfortunately there is still one small issue with the getopt files. Somehow the initial checkin of the getopt library seems to completely confuse tailor and 4 files don't seem to be tracked. So you will have to touch them up by hand afterwards. See comments in the script. If you want to play with the mercurial repository start with: hg clone http://gnu.wildebeest.org/hg/frysk That is a read-only repository. But be gentle (it is 115MB), that is my personal machine, it should auto update a few times a day, but no guarantees that I keep it going. You can however recreate a similar repository with the attached script and then just put it in some cron job to periodically update. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: convert-frysk-repo.sh Type: application/x-shellscript Size: 1619 bytes Desc: not available URL: -------------- next part -------------- [DEFAULT] verbose = True [project] target = hg:target start-revision = INITIAL root-directory = /home/mark/frysk-repo state-file = tailor.state source = cvs:source subdir = frysk-hg [hg:target] [cvs:source] module = frysk repository = /home/mark/frysk-repo/frysk-cvs From roland@redhat.com Tue Aug 7 07:52:00 2007 From: roland@redhat.com (Roland McGrath) Date: Tue, 07 Aug 2007 07:52:00 -0000 Subject: which elf symbol? In-Reply-To: Andrew Cagney's message of Thursday, 26 July 2007 18:30:55 -0400 <46A9209F.30103@redhat.com> Message-ID: <20070807075248.471754D04C4@magilla.localdomain> > What about a case like: > > symbol: > nop > unsized_symbol: > nop > .size symbol, .-symbol > 1: > > the closest symbol is unsized_symbol, but that is probably not the intent. Agreed. I think the correct answer for 1: here is no symbol. Below, this is case t4. > Yes, agreed. The sized symbol should trump the unsized one. Based on what you've said I'm now looking at the following test cases. For me, the current code gets all of these right except t4. I had the impression you had other cases where the current code yields the wrong answer. Please send me an assembly fragment in this style (e.g. t5, t6) on which you've verified addrsym yields the wrong answer, or let me know if cases like t4 are in fact the only specific known bug. I'd like to get these test cases firmly established ASAP, and before considering additional facilities with different behavior as for disassembly. Thanks, Roland .globl t1_global_outer t1_local_st_size_0: t1_global_outer: nop t1_local_in_global: nop .size t1_local_in_global, .-t1_local_in_global 1: nop # the right answer is t1_global_outer .size t1_global_outer, .-t1_global_outer .space 0x100 .balign 8 .globl t2_global_symbol t2_local_st_size_0: t2_global_symbol: nop nop 2: # the right answer is t2_global_symbol nop .size t2_global_symbol, .-t2_global_symbol .space 0x100 .balign 8 .globl t3_global_after_0 t3_global_after_0: nop t3_local_0_in_global: 3: # the right answer is t3_global_after_0 nop .size t3_global_after_0, .-t3_global_after_0 .space 0x100 .balign 8 .globl t4_global t4_global: nop t4_local_0_in_global: nop .size t4_global, .-t4_global 4: nop # the right answer is no answer nop .data t1_pc_of_interest: .long 1b t2_pc_of_interest: .long 2b t3_pc_of_interest: .long 3b t4_pc_of_interest: .long 4b From roland@redhat.com Tue Aug 7 09:04:00 2007 From: roland@redhat.com (Roland McGrath) Date: Tue, 07 Aug 2007 09:04:00 -0000 Subject: Dwarf expertise needed In-Reply-To: Sami Wagiaalla's message of Thursday, 26 July 2007 11:42:10 -0400 <46A8C0D2.5030905@redhat.com> Message-ID: <20070807090406.03A034D04C4@magilla.localdomain> > I am looking at this address 0x8048386: > > ./tests/addrscopes -e ../../frysk-core/frysk/pkglibdir/funit-scopes > 0x8048386 > ./tests/addrscopes: dwarf_getscopes: .debug_ranges section missing I have a fix for this case, but it is not exactly the same bug as Stan's case, the oriiginal https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230235 though you added your report there. I'm still looking at the original test cases. Thanks, Roland From scox@redhat.com Wed Aug 8 04:04:00 2007 From: scox@redhat.com (Stan Cox) Date: Wed, 08 Aug 2007 04:04:00 -0000 Subject: LocationExpression Message-ID: <1186545834.6921.14.camel@multics.rdu.redhat.com> I added a location expression evaluator I wrote a while back to replace the current location heuristics. It is implemented as a pushdown stack machine similar to what the dwarf doc describes. It is not complete, as some operators are missing and unsigned is not handled completely. frysk-core/frysk/debuginfo/LocationExpression.java From mark@klomp.org Wed Aug 8 10:15:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 08 Aug 2007 10:15:00 -0000 Subject: LocationExpression In-Reply-To: <1186545834.6921.14.camel@multics.rdu.redhat.com> References: <1186545834.6921.14.camel@multics.rdu.redhat.com> Message-ID: <1186568104.29962.5.camel@dijkstra.wildebeest.org> Hi Stan, On Wed, 2007-08-08 at 00:03 -0400, Stan Cox wrote: > frysk-core/frysk/debuginfo/LocationExpression.java This doesn't compile on FC6. I didn't know that you could actually throw a 'null', and so didn't the compiler :) But you are right according to the spec that this is allowed and the semantics is precisely as if you actually created a new NullPointerException at that place and then threw it. So the fix is obvious: 2007-08-08 Mark Wielaard * LocationExpression.java (getRegisterNumber): Throw NullPointerException. diff -u -r1.1 LocationExpression.java --- frysk-core/frysk/debuginfo/LocationExpression.java 8 Aug 2007 03:42:45 -0000 1.1 +++ frysk-core/frysk/debuginfo/LocationExpression.java 8 Aug 2007 09:54:27 -0000 @@ -263,6 +263,6 @@ } else throw new ValueUavailableException(); - throw null; + throw new NullPointerException(); } } Which is what I committed. Cheers, Mark BTW. Are you sure you want to model this case with a NullPointerException? Personally I would add a reason to the ValueUavailableException and use that to differentiate between the various ways that the LocationExpression couldn't be constructed, then you could present that cause to the user (which might help us with bug reports). Idea for a patch attached (but not committed). BTW2. I would have expected ValueUnavailableException (with an 'n'). -------------- next part -------------- A non-text attachment was scrubbed... Name: ValueUavailableException.patch Type: text/x-patch Size: 2039 bytes Desc: not available URL: From pmachata@redhat.com Wed Aug 8 11:04:00 2007 From: pmachata@redhat.com (Petr Machata) Date: Wed, 08 Aug 2007 11:04:00 -0000 Subject: LocationExpression In-Reply-To: <1186568104.29962.5.camel@dijkstra.wildebeest.org> References: <1186545834.6921.14.camel@multics.rdu.redhat.com> <1186568104.29962.5.camel@dijkstra.wildebeest.org> Message-ID: <46B9A32F.1020400@redhat.com> Mark Wielaard wrote: > This doesn't compile on FC6. I didn't know that you could actually throw > a 'null', and so didn't the compiler :) But you are right according to > the spec that this is allowed and the semantics is precisely as if you > actually created a new NullPointerException at that place and then threw > it. Interesting, I was thinking that maybe this is a typo that was supposed to read "return null" instead of "throw null"... PM -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From scox@redhat.com Wed Aug 8 12:24:00 2007 From: scox@redhat.com (Stan Cox) Date: Wed, 08 Aug 2007 12:24:00 -0000 Subject: LocationExpression In-Reply-To: <1186568104.29962.5.camel@dijkstra.wildebeest.org> References: <1186545834.6921.14.camel@multics.rdu.redhat.com> <1186568104.29962.5.camel@dijkstra.wildebeest.org> Message-ID: <1186575834.6921.33.camel@multics.rdu.redhat.com> On Wed, 2007-08-08 at 12:15 +0200, Mark Wielaard wrote: > This doesn't compile on FC6. Thanks for catching it. Yea it was a typo for return null, meant to silence a warning with gcj 4.1.2 20070502. Didn't mean to throw it of course, but it compiled with that compiler. By the way, the current use of LocationExpression is in DebugInfoEvaluator.java#get. First it tries the get* methods in AccessMemory; this is for cases where a symbol is accessed by address or register+offset. If that fails then it tries the get* methods in AccessRegisters; this is for cases where a symbol is in a register. These are the only cases currently supported by LocationExpression. From kris.van.hees@oracle.com Wed Aug 8 12:55:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Wed, 08 Aug 2007 12:55:00 -0000 Subject: Absent from the unannounced call Message-ID: <20070808125441.GA26500@oracle.com> I will not be able to join the Frysk conference call today, assuming there is one since no announcement has been posted yet. Cheers, Kris From cagney@redhat.com Wed Aug 8 13:23:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 08 Aug 2007 13:23:00 -0000 Subject: frysk meeting 2007-08-09 9:30 US east Message-ID: <46B9C3C7.5090002@redhat.com> [yes running late; please contact me for dail in info] This week: - frysk-asm.h walk through - C++ types - more debuginfo From mark@klomp.org Wed Aug 8 15:25:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 08 Aug 2007 15:25:00 -0000 Subject: frysk meeting 2007-08-09 9:30 US east In-Reply-To: <46B9C3C7.5090002@redhat.com> References: <46B9C3C7.5090002@redhat.com> Message-ID: <1186586732.29962.25.camel@dijkstra.wildebeest.org> Hi, Small transcript saved: On Wed, 2007-08-08 at 09:23 -0400, Andrew Cagney wrote: > - frysk-asm.h walk through We wnet over the folliwing files: $ less frysk-core/frysk/pkglibdir/funit-frameless.S $ less frysk-imports/include/funit-util.h $ less frysk-imports/include/frysk-asm.h $ less frysk-imports/include/frysk-asm.h $ less frysk-core/frysk/pkglibdir/funit-symbols.S The frysk-asm.h files has lots and lots of comments. $ info gas Will give you documentation on the .cif assembler directives used. * Pseudo Ops:: Assembler Directives * CFI directives:: `.cfi_startproc', `.cfi_endproc', etc. http://sourceware.org/binutils/docs-2.17/as/CFI-directives.html (I must have missed this before, because I was looking for it, but only found the gas 2.9 manual online previously, which doesn't seem to support the cfi directives.) > - C++ types Stan was smart and had a premade demo, which is attached. > - more debuginfo $ ./frysk-core/frysk/bindir/fhpd $$ Attached to process 5784 (fhpd) de debuginfo defset delete detach (fhpd) debuginfo /lib/libnss_files-2.6.so /usr/lib/debug/lib/libnss_files-2.6.so.debug /lib/ld-2.6.so /usr/lib/debug/lib/ld-2.6.so.debug /lib/libc-2.6.so /usr/lib/debug/lib/libc-2.6.so.debug /lib/libdl-2.6.so /usr/lib/debug/lib/libdl-2.6.so.debug /lib/libtinfo.so.5.6 /usr/lib/debug/lib/libtinfo.so.5.6.debug /bin/bash /usr/lib/debug/bin/bash.debug (fhpd) quit Quitting... $ ./frysk/bindir/fdebuginfo $$ /lib/libnss_files-2.6.so /usr/lib/debug/lib/libnss_files-2.6.so.debug /lib/ld-2.6.so /usr/lib/debug/lib/ld-2.6.so.debug /lib/libc-2.6.so /usr/lib/debug/lib/libc-2.6.so.debug /lib/libdl-2.6.so /usr/lib/debug/lib/libdl-2.6.so.debug /lib/libtinfo.so.5.6 /usr/lib/debug/lib/libtinfo.so.5.6.debug /bin/bash /usr/lib/debug/bin/bash.debug $ ./frysk/bindir/fcore $$ $ ./frysk/bindir/fdebuginfo core.$$ Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String ind ex out of range: 0 at java.lang.String.charAt(libgcj.so.8rh) at frysk.util.DebuginfoPaths.getDebuginfo(fdebuginfo) at frysk.bindir.fdebuginfo.printDebuginfo(fdebuginfo) at frysk.bindir.fdebuginfo.access$0(fdebuginfo) at frysk.bindir.fdebuginfo$1.parseCores(fdebuginfo) at frysk.util.CommandlineParser.doParse(fdebuginfo) at frysk.util.CommandlineParser.parse(fdebuginfo) at frysk.bindir.fdebuginfo.main(fdebuginfo) [... bah! That is no good. After some debugging we came up with ...] $ cvs diff frysk-core/frysk/util Index: frysk-core/frysk/util/DebuginfoPaths.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/util/DebuginfoPaths.java,v retrieving revision 1.1 diff -u -r1.1 DebuginfoPaths.java --- frysk-core/frysk/util/DebuginfoPaths.java 7 Aug 2007 15:26:24 -0000 1.1 +++ frysk-core/frysk/util/DebuginfoPaths.java 8 Aug 2007 14:49:32 -0000 @@ -77,7 +77,7 @@ String name = mod.getName(); // Check for valid executables - if (name.charAt(0)=='/') + if (name.length() != 0 && name.charAt(0)=='/') { // Ignore non-binary modules if (mod.getElf()==null) $ ./frysk/bindir/fdebuginfo core.$$ /lib/ld-linux.so.2 /usr/lib/debug/lib/ld-2.6.so.debug /lib/libc.so.6 /usr/lib/debug/lib/libc-2.6.so.debug /lib/libdl.so.2 /usr/lib/debug/lib/libdl-2.6.so.debug /lib/libtinfo.so.5 /usr/lib/debug/lib/libtinfo.so.5.6.debug /bin/bash /usr/lib/debug/bin/bash.debug [... But this is slightly strange, needs investigation, why is the name empty in the first place? Phil and Mark think it might be the vdso module name ...] $ uname -a Linux hermans.wildebeest.org 2.6.22.1-41.fc7 #1 SMP Fri Jul 27 18:10:34 EDT 2007 i686 i686 i386 GNU/Linux $ grep vdso /proc/$$/maps 00110000-00111000 r-xp 00110000 00:00 0 [vdso] -------------- next part -------------- A non-text attachment was scrubbed... Name: session Type: text/x-csrc Size: 3101 bytes Desc: not available URL: From scox@redhat.com Wed Aug 8 19:59:00 2007 From: scox@redhat.com (Stan Cox) Date: Wed, 08 Aug 2007 19:59:00 -0000 Subject: tab completion Message-ID: <1186603143.6921.45.camel@multics.rdu.redhat.com> Tab completion is a feature of jline. fhpd.java sets it up by defining a class FhpdCompletor which defines CLI.complete as the completor. This method uses heuristics to determine what is being completed. If the fhpd request line doesn't contain spaces then it is assumed that request names are being completed. This is done by calling candidates.add to add each request names that match the input thus far. Then complete returns the position in the input line where completion will continue to jline. If request names are not being completed then debugInfo.complete is called as the completor. This method interrogates the debuginfo to find candidate names. DwarfDie.getScopeVarNames does most of the work of finding candidate names. candidates.add is called to add matching names. Structure members are handled specially by getScopeVarNames by returning the structure members. From thomas.g.girard@free.fr Thu Aug 9 08:27:00 2007 From: thomas.g.girard@free.fr (Thomas Girard) Date: Thu, 09 Aug 2007 08:27:00 -0000 Subject: Questions about build web documentation Message-ID: <1186647756.3865.14.camel@micmac> Hello, I have started modifying the htdocs/build/index.html file to add sections for Debian (and Ubuntu Gutsy Gibbon). There's something I don't understand about this page: according to it jdom, junit and junit packages are required to build frysk. But they're not because they are available from frysk-imports. Am I missing something? (Besides, using system versions of these libraries - as we do for Debian frysk package - require tweaking some autotools files.) Thanks, Regards, Thomas From mark@klomp.org Thu Aug 9 10:24:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Thu, 09 Aug 2007 10:24:00 -0000 Subject: Questions about build web documentation In-Reply-To: <1186647756.3865.14.camel@micmac> References: <1186647756.3865.14.camel@micmac> Message-ID: <1186655070.3747.12.camel@dijkstra.wildebeest.org> Hi Thomas, On Thu, 2007-08-09 at 10:22 +0200, Thomas Girard wrote: > I have started modifying the htdocs/build/index.html file to add > sections for Debian (and Ubuntu Gutsy Gibbon). Thanks, great. > There's something I don't understand about this page: according to it > jdom, junit and junit packages are required to build frysk. But they're > not because they are available from frysk-imports. Am I missing > something? (Besides, using system versions of these libraries - as we do > for Debian frysk package - require tweaking some autotools files.) This might be slightly outdated then. antlr and jdom jars are used from the system if found (see frysk-imports/configure.ac), for junit, cdtparser, jline and getopt, we do include the upstream sources (see the frysk-import/ subdirs) and compile those to jar files. Then in frysk-imports/bootstrap.sh (FILE_LIST) we feed those, and the detected antlr and jdom jars, to common/Makefile.gen.sh that creates a frysk-imports/Makefile.gen, that is included in the frysk-imports/Makefile.am so that we finally generate native shared libraries from them, which we link against. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From swagiaal@redhat.com Thu Aug 9 17:06:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Thu, 09 Aug 2007 17:06:00 -0000 Subject: Dwarf expertise needed In-Reply-To: <20070807090406.03A034D04C4@magilla.localdomain> References: <20070807090406.03A034D04C4@magilla.localdomain> Message-ID: <46BB4979.3060103@redhat.com> Roland McGrath wrote: >> I am looking at this address 0x8048386: >> >> ./tests/addrscopes -e ../../frysk-core/frysk/pkglibdir/funit-scopes >> 0x8048386 >> ./tests/addrscopes: dwarf_getscopes: .debug_ranges section missing >> > > I have a fix for this case, but it is not exactly the same bug as Stan's case, > the oriiginal https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230235 > though you added your report there. > > I'm still looking at the original test cases. > Sweet!.. Yea there was a long period between when I edited the bug report and when I actually looked into it and realized its different. Thanks, Sami From cagney@redhat.com Thu Aug 9 22:33:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 09 Aug 2007 22:33:00 -0000 Subject: funit-slave replacing funit-child Message-ID: <46BB9622.20006@redhat.com> Just a heads up; I'm replacing the program funit-child with the slightly friendlier and largely equivalent funit-slave. Why is it friendlier? -> if you invoke funit-slave with no parameters it will run with an infinite timeout (before an explicit timeout was needed) -> if you hit cntrl-c, it exits (before that would cause it to clone) Why is it largely equivalent? -> The options changed (it is using getopt); see -h or the man page -> it does not contain code for testing breakpoints From pmuldoon@redhat.com Thu Aug 9 23:10:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 09 Aug 2007 23:10:00 -0000 Subject: frysk-core/frysk hpd/AllPTSet.java hpd/CLI.jav ... In-Reply-To: <20070809170656.7895.qmail@sourceware.org> References: <20070809170656.7895.qmail@sourceware.org> Message-ID: <46BB9ED1.40100@redhat.com> Tim At first glance, and I could be wrong, but this commit appears to have broken all core file operations in fhpd. [pmuldoon@localhost bindir]$ ./fhpd core.3260 /bin/bash Attached to core file: /home/pmuldoon/frysk_bin/frysk-core/frysk/bindir/core.3260 (fhpd) where java.lang.ClassCastException: frysk.hpd.TaskData cannot be cast to frysk.proc.Task at frysk.hpd.WhereCommand.handle(WhereCommand.java:72) at frysk.hpd.CLI.execCommand(CLI.java:436) at frysk.bindir.fhpd.main(fhpd.java:148) Internal debugger error: frysk.hpd.TaskData cannot be cast to frysk.proc.Task (fhpd) quit java.lang.ClassCastException: frysk.hpd.TaskData cannot be cast to frysk.proc.Task at frysk.hpd.DetachCommand.handle(DetachCommand.java:68) at frysk.hpd.QuitCommand.handle(QuitCommand.java:67) at frysk.hpd.CLI.execCommand(CLI.java:436) at frysk.bindir.fhpd.main(fhpd.java:148) Quitting... Internal debugger error: frysk.hpd.TaskData cannot be cast to frysk.proc.Task moore@sourceware.org wrote: > CVSROOT: /cvs/frysk > Module name: frysk-core > Changes by: moore@sourceware.org 2007-08-09 17:06:56 > > Modified files: > frysk/hpd : AllPTSet.java CLI.java ChangeLog > frysk/rt : ChangeLog > Added files: > frysk/rt : ProcTaskIDManager.java > Removed files: > frysk/hpd : TestSetCreation.java > > Log message: > Infrastructure for ptsets based on real processes and tasks > > frysk-core/frysk/hpd/ChangeLog > 2007-08-08 Tim Moore > > * AllPTSet.java: Complete rewrite to reference active Procs and > Tasks via the ProcTaskIDManager. > * CLI.java (idManager): New variable, reference to > ProcTaskIDManager. > (startAttach): Only initialize steppingEngine once. > (CLI): Initialize idManager. > (getCommandPTSet): New method. > * TestSetCreation.java: Remove file because AllPTSet doesn't > support creation of random proc/task numbers anymore. > > frysk-core/frysk/rt/ChangeLog > 2007-08-08 Tim Moore > > * ProcTaskIDManager.java: New file. > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/hpd/AllPTSet.java.diff?cvsroot=frysk&r1=1.1&r2=1.2 > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/hpd/CLI.java.diff?cvsroot=frysk&r1=1.7&r2=1.8 > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/hpd/ChangeLog.diff?cvsroot=frysk&r1=1.27&r2=1.28 > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/hpd/TestSetCreation.java.diff?cvsroot=frysk&r1=1.1&r2=NONE > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/rt/ProcTaskIDManager.java.diff?cvsroot=frysk&r1=NONE&r2=1.1 > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/rt/ChangeLog.diff?cvsroot=frysk&r1=1.352&r2=1.353 > > From pmuldoon@redhat.com Fri Aug 10 00:04:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 10 Aug 2007 00:04:00 -0000 Subject: frysk-core/frysk hpd/AllPTSet.java hpd/CLI.jav ... In-Reply-To: <46BB9ED1.40100@redhat.com> References: <20070809170656.7895.qmail@sourceware.org> <46BB9ED1.40100@redhat.com> Message-ID: <46BBAB69.8050008@redhat.com> I did a simple adjustment here [pmuldoon@localhost hpd]$ cvs diff WhereCommand.java Index: WhereCommand.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/hpd/WhereCommand.java,v retrieving revision 1.4 diff -u -p -r1.4 WhereCommand.java --- WhereCommand.java 9 Aug 2007 17:13:49 -0000 1.4 +++ WhereCommand.java 9 Aug 2007 23:50:07 -0000 @@ -69,7 +69,7 @@ class WhereCommand level = Integer.parseInt((String)params.get(0)); Iterator taskIter = ptset.getTasks(); while (taskIter.hasNext()) { - Task task = (Task)taskIter.next(); + Task task = ((TaskData)taskIter.next()).getTask(); DebugInfoFrame tmpFrame = null; int l = cli.getTaskStackLevel(task); int stopLevel; And that makes it work for corefile tasks, but fail for live tasks with the exception: [pmuldoon@localhost bindir]$ ./fhpd 15630 Attached to process 15630 (fhpd) where Inside where command java.lang.ClassCastException: frysk.proc.live.LinuxTask cannot be cast to frysk.hpd.TaskData at frysk.hpd.WhereCommand.handle(WhereCommand.java:74) at frysk.hpd.CLI.execCommand(CLI.java:436) at frysk.bindir.fhpd.main(fhpd.java:148) Internal debugger error: frysk.proc.live.LinuxTask cannot be cast to frysk.hpd.TaskData Could be a case of weak typing? Plugged green wire into red jack and all that ;) Regards Phil Phil Muldoon wrote: > Tim > > At first glance, and I could be wrong, but this commit appears to have > broken all core file operations in fhpd. > > [pmuldoon@localhost bindir]$ ./fhpd core.3260 /bin/bash > Attached to core file: > /home/pmuldoon/frysk_bin/frysk-core/frysk/bindir/core.3260 > (fhpd) where > java.lang.ClassCastException: frysk.hpd.TaskData cannot be cast to > frysk.proc.Task > at frysk.hpd.WhereCommand.handle(WhereCommand.java:72) > at frysk.hpd.CLI.execCommand(CLI.java:436) > at frysk.bindir.fhpd.main(fhpd.java:148) > Internal debugger error: frysk.hpd.TaskData cannot be cast to > frysk.proc.Task > (fhpd) quit > java.lang.ClassCastException: frysk.hpd.TaskData cannot be cast to > frysk.proc.Task > at frysk.hpd.DetachCommand.handle(DetachCommand.java:68) > at frysk.hpd.QuitCommand.handle(QuitCommand.java:67) > at frysk.hpd.CLI.execCommand(CLI.java:436) > at frysk.bindir.fhpd.main(fhpd.java:148) > Quitting... > Internal debugger error: frysk.hpd.TaskData cannot be cast to > frysk.proc.Task > > > moore@sourceware.org wrote: >> CVSROOT: /cvs/frysk >> Module name: frysk-core >> Changes by: moore@sourceware.org 2007-08-09 17:06:56 >> >> Modified files: >> frysk/hpd : AllPTSet.java CLI.java ChangeLog >> frysk/rt : ChangeLog Added files: >> frysk/rt : ProcTaskIDManager.java Removed files: >> frysk/hpd : TestSetCreation.java >> Log message: >> Infrastructure for ptsets based on real processes and tasks >> >> frysk-core/frysk/hpd/ChangeLog >> 2007-08-08 Tim Moore >> >> * AllPTSet.java: Complete rewrite to reference active Procs and >> Tasks via the ProcTaskIDManager. >> * CLI.java (idManager): New variable, reference to >> ProcTaskIDManager. >> (startAttach): Only initialize steppingEngine once. >> (CLI): Initialize idManager. >> (getCommandPTSet): New method. >> * TestSetCreation.java: Remove file because AllPTSet doesn't >> support creation of random proc/task numbers anymore. >> >> frysk-core/frysk/rt/ChangeLog >> 2007-08-08 Tim Moore >> >> * ProcTaskIDManager.java: New file. >> >> Patches: >> http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/hpd/AllPTSet.java.diff?cvsroot=frysk&r1=1.1&r2=1.2 >> >> http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/hpd/CLI.java.diff?cvsroot=frysk&r1=1.7&r2=1.8 >> >> http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/hpd/ChangeLog.diff?cvsroot=frysk&r1=1.27&r2=1.28 >> >> http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/hpd/TestSetCreation.java.diff?cvsroot=frysk&r1=1.1&r2=NONE >> >> http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/rt/ProcTaskIDManager.java.diff?cvsroot=frysk&r1=NONE&r2=1.1 >> >> http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/rt/ChangeLog.diff?cvsroot=frysk&r1=1.352&r2=1.353 >> >> >> > > From pmuldoon@redhat.com Fri Aug 10 01:49:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 10 Aug 2007 01:49:00 -0000 Subject: frysk-core/frysk hpd/AllPTSet.java hpd/CLI.jav ... In-Reply-To: <46BBAB69.8050008@redhat.com> References: <20070809170656.7895.qmail@sourceware.org> <46BB9ED1.40100@redhat.com> <46BBAB69.8050008@redhat.com> Message-ID: <46BBC434.3080708@redhat.com> Think I fixed it. The below patch returns the correct ArrayList iterator in StaticPTSet. Tasks are now returned over TaskData. Index: StaticPTSet.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/hpd/StaticPTSet.java,v retrieving revision 1.1 diff -u -p -r1.1 StaticPTSet.java --- StaticPTSet.java 25 Jul 2007 00:37:25 -0000 1.1 +++ StaticPTSet.java 10 Aug 2007 01:48:05 -0000 @@ -98,7 +98,7 @@ class StaticPTSet implements PTSet result.add( ((TaskData) temp.get(j)).getTask() ); } - return temp.iterator(); + return result.iterator(); } public Iterator getTaskData() Phil Muldoon wrote: > I did a simple adjustment here > > [pmuldoon@localhost hpd]$ cvs diff WhereCommand.java > Index: WhereCommand.java > =================================================================== > RCS file: /cvs/frysk/frysk-core/frysk/hpd/WhereCommand.java,v > retrieving revision 1.4 > diff -u -p -r1.4 WhereCommand.java > --- WhereCommand.java 9 Aug 2007 17:13:49 -0000 1.4 > +++ WhereCommand.java 9 Aug 2007 23:50:07 -0000 > @@ -69,7 +69,7 @@ class WhereCommand > level = Integer.parseInt((String)params.get(0)); > Iterator taskIter = ptset.getTasks(); > while (taskIter.hasNext()) { > - Task task = (Task)taskIter.next(); > + Task task = ((TaskData)taskIter.next()).getTask(); > DebugInfoFrame tmpFrame = null; > int l = cli.getTaskStackLevel(task); > int stopLevel; > > And that makes it work for corefile tasks, but fail for live tasks > with the exception: > > [pmuldoon@localhost bindir]$ ./fhpd 15630 > Attached to process 15630 > (fhpd) where > Inside where command > java.lang.ClassCastException: frysk.proc.live.LinuxTask cannot be cast > to frysk.hpd.TaskData > at frysk.hpd.WhereCommand.handle(WhereCommand.java:74) > at frysk.hpd.CLI.execCommand(CLI.java:436) > at frysk.bindir.fhpd.main(fhpd.java:148) > Internal debugger error: frysk.proc.live.LinuxTask cannot be cast to > frysk.hpd.TaskData > > > Could be a case of weak typing? Plugged green wire into red jack and > all that ;) > > > Regards > > Phil > > Phil Muldoon wrote: >> Tim >> >> At first glance, and I could be wrong, but this commit appears to have >> broken all core file operations in fhpd. >> >> [pmuldoon@localhost bindir]$ ./fhpd core.3260 /bin/bash >> Attached to core file: >> /home/pmuldoon/frysk_bin/frysk-core/frysk/bindir/core.3260 >> (fhpd) where >> java.lang.ClassCastException: frysk.hpd.TaskData cannot be cast to >> frysk.proc.Task > >> at frysk.hpd.WhereCommand.handle(WhereCommand.java:72) >> at frysk.hpd.CLI.execCommand(CLI.java:436) >> at frysk.bindir.fhpd.main(fhpd.java:148) >> Internal debugger error: frysk.hpd.TaskData cannot be cast to >> frysk.proc.Task >> (fhpd) quit >> java.lang.ClassCastException: frysk.hpd.TaskData cannot be cast to >> frysk.proc.Task >> at frysk.hpd.DetachCommand.handle(DetachCommand.java:68) >> at frysk.hpd.QuitCommand.handle(QuitCommand.java:67) >> at frysk.hpd.CLI.execCommand(CLI.java:436) >> at frysk.bindir.fhpd.main(fhpd.java:148) >> Quitting... >> Internal debugger error: frysk.hpd.TaskData cannot be cast to >> frysk.proc.Task >> >> >> moore@sourceware.org wrote: >>> CVSROOT: /cvs/frysk >>> Module name: frysk-core >>> Changes by: moore@sourceware.org 2007-08-09 17:06:56 >>> >>> Modified files: >>> frysk/hpd : AllPTSet.java CLI.java ChangeLog >>> frysk/rt : ChangeLog Added files: >>> frysk/rt : ProcTaskIDManager.java Removed files: >>> frysk/hpd : TestSetCreation.java >>> Log message: >>> Infrastructure for ptsets based on real processes and tasks >>> frysk-core/frysk/hpd/ChangeLog >>> 2007-08-08 Tim Moore >>> * AllPTSet.java: Complete rewrite to reference active Procs and >>> Tasks via the ProcTaskIDManager. >>> * CLI.java (idManager): New variable, reference to >>> ProcTaskIDManager. >>> (startAttach): Only initialize steppingEngine once. >>> (CLI): Initialize idManager. >>> (getCommandPTSet): New method. >>> * TestSetCreation.java: Remove file because AllPTSet doesn't >>> support creation of random proc/task numbers anymore. >>> frysk-core/frysk/rt/ChangeLog >>> 2007-08-08 Tim Moore >>> * ProcTaskIDManager.java: New file. >>> >>> Patches: >>> http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/hpd/AllPTSet.java.diff?cvsroot=frysk&r1=1.1&r2=1.2 >>> >>> http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/hpd/CLI.java.diff?cvsroot=frysk&r1=1.7&r2=1.8 >>> >>> http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/hpd/ChangeLog.diff?cvsroot=frysk&r1=1.27&r2=1.28 >>> >>> http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/hpd/TestSetCreation.java.diff?cvsroot=frysk&r1=1.1&r2=NONE >>> >>> http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/rt/ProcTaskIDManager.java.diff?cvsroot=frysk&r1=NONE&r2=1.1 >>> >>> http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/rt/ChangeLog.diff?cvsroot=frysk&r1=1.352&r2=1.353 >>> >>> >>> >> >> > From pearly.zhao@oracle.com Fri Aug 10 09:26:00 2007 From: pearly.zhao@oracle.com (Zhao Shujing) Date: Fri, 10 Aug 2007 09:26:00 -0000 Subject: [patch] fix bugs of memory window Message-ID: <1186738176.11132.42.camel@linux-pzhao.site> Hi, Can anyone help me to review the attached patch? Thanks. I have tested at x86_64/FC7. The patch is mainly to fix the following bugs of memory window: - fromSpin.setValue would invoke the fromSpin entryEvent again, so the handleFromSpin is called twice. It happens at toSpin too. - Prepend row by order from low to high when decrease fromBox. - removeRow would make iter to set to the next valid row, iter.getNextIter is not needed after removeRow. The above-mentioned are happened at disassembly window too. But only fixing these bugs can not make the window display correctly yet. So there is no patch for disassembly window this time. BTW: I'm touching GUI test and the disassembly window and memory window refactoring. Any suggestions are welcomed. 2007-08-10 Zhao Shujing *memory/MemoryWindow.java (fromBox.entryEvent): Use fromSpin.setValue to invoke fromSpin entryEvent. (toBox.entryEvent): Ditto. (handleToSpin): Ditto. (handleFromSpin): Prepend row by the order from high to low. Thanks Pearly -------------- next part -------------- A non-text attachment was scrubbed... Name: memory.patch Type: text/x-patch Size: 2596 bytes Desc: URL: From thomas.g.girard@free.fr Sun Aug 12 20:38:00 2007 From: thomas.g.girard@free.fr (Thomas Girard) Date: Sun, 12 Aug 2007 20:38:00 -0000 Subject: Questions about build web documentation In-Reply-To: <1186655070.3747.12.camel@dijkstra.wildebeest.org> References: <1186647756.3865.14.camel@micmac> <1186655070.3747.12.camel@dijkstra.wildebeest.org> Message-ID: <1186950854.3853.29.camel@micmac> Hello, Le jeudi 09 ao??t 2007 ?? 12:24 +0200, Mark Wielaard a ??crit : > > There's something I don't understand about this page: according to it > > jdom, junit and junit packages are required to build frysk. But they're > > not because they are available from frysk-imports. Am I missing > > something? (Besides, using system versions of these libraries - as we do > > for Debian frysk package - require tweaking some autotools files.) > > This might be slightly outdated then. antlr and jdom jars are used from > the system if found (see frysk-imports/configure.ac), for junit, > cdtparser, jline and getopt, we do include the upstream sources (see the > frysk-import/ subdirs) and compile those to jar files. Then in > frysk-imports/bootstrap.sh (FILE_LIST) we feed those, and the detected > antlr and jdom jars, to common/Makefile.gen.sh that creates a > frysk-imports/Makefile.gen, that is included in the > frysk-imports/Makefile.am so that we finally generate native shared > libraries from them, which we link against. Thanks for the explanation. Please review the attached patch for htdocs/build/index.html. I'm wondering if tracker bugs sould be split for Ubuntu and Debian releases the way they are for Red Hat? Regards, Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: htdocs_build.diff Type: text/x-patch Size: 1281 bytes Desc: not available URL: From mark@klomp.org Tue Aug 14 09:48:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 14 Aug 2007 09:48:00 -0000 Subject: frysk-core/frysk debuginfo/ChangeLog debuginfo ... In-Reply-To: <20070813234217.10990.qmail@sourceware.org> References: <20070813234217.10990.qmail@sourceware.org> Message-ID: <1187084861.3805.2.camel@dijkstra.wildebeest.org> Hi Andrew, On Mon, 2007-08-13 at 23:42 +0000, cagney@sourceware.org wrote: > 2007-08-13 Andrew Cagney > > * Value.java (asLong): Replace longValue. > (intValue): Delete. > * ArithmeticType.java: Use asLong. > * PointerType.java: Ditto. Found one more place this needed replaced. Fixed as follows: 2007-08-14 Mark Wielaard * InlineSourceView.java (mouseEvent): Use asLong instead of longValue. Cheers, Mark diff -u -r1.19 InlineSourceView.java --- frysk-gui/frysk/gui/srcwin/InlineSourceView.java 31 Jul 2007 20:31:50 -0000 1.19 +++ frysk-gui/frysk/gui/srcwin/InlineSourceView.java 14 Aug 2007 09:39:00 -0000 @@ -240,7 +240,7 @@ if (var != null) { MenuItem valueItem; - valueItem = new MenuItem("Value: " + var.longValue(), true); + valueItem = new MenuItem("Value: " + var.asLong(), true); valueItem.setSensitive(false); m.append(valueItem); From cagney@redhat.com Tue Aug 14 15:23:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 14 Aug 2007 15:23:00 -0000 Subject: toPrint vs toString Message-ID: <46C1C8E8.4060805@redhat.com> toString(): for dumping internal object state --------------------------------------------- Just a reminder; Java's Object class includes a <> method that can be overridden (by default it prints the object's address and type) to dump out an objects internal state. That way, when printing or tracing this method is called vis: System.out.println("my " + task); // uses Task.toString logger.log(Level.FINE, "{0} task\n", task); // ditto and debugging level information is provided. However, within frysk, toString() or variations shouldn't be used when creating output intended for the user. toPrint(): for displaying an object user friendly ------------------------------------------------- If the output is intended for the user, the add a toPrint() method and use that. There are two variations. The first sends the output to a Writer vis: public void toPrint(PrintWriter writer) ... writer.print ... and the second, if you find it necessary, just wraps the first vis: public void toPrint() stringWriter = new StringBuffer() printWriter = new PrintWriter(stringWriter) toPrint(printWriter) return stringWriter.toString(); For instance, frysk.value.Value as methods such as: public void toPrint(PrintWriter writer, ByteBuffer memory, Format format) public String toPrint() { ... see above ... } for converting a value in to a user-readable form. From swagiaal@redhat.com Tue Aug 14 15:35:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Tue, 14 Aug 2007 15:35:00 -0000 Subject: toPrint vs toString In-Reply-To: <46C1C8E8.4060805@redhat.com> References: <46C1C8E8.4060805@redhat.com> Message-ID: <46C1CBC3.4000308@redhat.com> > public void toPrint() > stringWriter = new StringBuffer() > printWriter = new PrintWriter(stringWriter) > toPrint(printWriter) > return stringWriter.toString(); this should be stringWriter.getBuffer().toString(); From cagney@redhat.com Tue Aug 14 16:41:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 14 Aug 2007 16:41:00 -0000 Subject: adding print methods to frysk.value.Format Message-ID: <46C1DB26.80200@redhat.com> Just FYI, I've gone through the code and removed a number of cases where frysk.value.Format was being treated as an enum, for instance: if (format == Format.HEXACECIMAL) print as hex else if (format == Format.DECIMAL) print as decimal ... (and similarly for the Type's typeId). This should instead be implemented by extending Format to handle the type in question, for instance: format.printPointer(PrintWriter, location-of-data) While there were no test-suite regressions, I suspect, as the better implemented code is filled in, there may be some lurking untested user-visible regressions. Andrew From kris.van.hees@oracle.com Tue Aug 14 16:44:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Tue, 14 Aug 2007 16:44:00 -0000 Subject: toPrint vs toString In-Reply-To: <46C1CBC3.4000308@redhat.com> References: <46C1C8E8.4060805@redhat.com> <46C1CBC3.4000308@redhat.com> Message-ID: <20070814164318.GB12525@oracle.com> On Tue, Aug 14, 2007 at 11:35:31AM -0400, Sami Wagiaalla wrote: > >> public void toPrint() >> stringWriter = new StringBuffer() >> printWriter = new PrintWriter(stringWriter) >> toPrint(printWriter) >> return stringWriter.toString(); > this should be stringWriter.getBuffer().toString(); Hm, more like: public String toPrint() { StringWriter stringWriter = new StringWriter(); PrintWriter printWriter = new PrintWriter(stringWriter); toPrint(printWriter); return stringWriter.toString(); } because: 1) You cannot pass a StringBuffer to PrinterWriter's contructor 2) StringBuffer doesn't have a getBuffer() method 3) StringWriter has a toString() method 4) You can't return a String from a method that declares its return type as 'void' obviously Either way perhaps it is safer in cases like this to point to existing code (that is known to compile, etc) as an example on how to use specific constructs? Cheers, Kris From swagiaal@redhat.com Tue Aug 14 17:12:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Tue, 14 Aug 2007 17:12:00 -0000 Subject: toPrint vs toString In-Reply-To: <46C1CBC3.4000308@redhat.com> References: <46C1C8E8.4060805@redhat.com> <46C1CBC3.4000308@redhat.com> Message-ID: <46C1E262.7030104@redhat.com> Sami Wagiaalla wrote: > >> public void toPrint() >> stringWriter = new StringBuffer() >> printWriter = new PrintWriter(stringWriter) >> toPrint(printWriter) >> return stringWriter.toString(); > this should be stringWriter.getBuffer().toString(); > nm... I thought I was saving people from a trap I fell into but it looks like it works. my bad. Sami From mcvet@redhat.com Tue Aug 14 19:44:00 2007 From: mcvet@redhat.com (Mike Cvet) Date: Tue, 14 Aug 2007 19:44:00 -0000 Subject: All stepping operations enabled Message-ID: <46C20619.8040906@redhat.com> Hey all, I've just committed a change which enables the next, nexti, and finish (step-over, step-over instruction, and step-out) operations in both the fhpd and debugging window. What does this mean for you? It depends. If the C program you wish to debug has not been compiled with -fasynchronous-unwind-tables, then likely not much is going to happen. This flag is critical for providing the necessary .eh_frame sections for the above stepping operations - so if you'd like it give it a shot, please append it to the CFLAGS of the target process. Thus, with the above requirements, all the stepping operations in the source window and fhpd have been enabled. Enjoy! - Mike From cagney@redhat.com Wed Aug 15 01:32:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 15 Aug 2007 01:32:00 -0000 Subject: meeting 2007-08-15 9:30 us east coast time Message-ID: <46C257B2.5030903@redhat.com> [all welcome, contact me on irc for dial in info] This week: -> sam would like to go some use cases involving inlined code and stack frames From mark@klomp.org Wed Aug 15 08:14:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 15 Aug 2007 08:14:00 -0000 Subject: TestLib assertStatState() Message-ID: <1187165651.3804.12.camel@dijkstra.wildebeest.org> Hi, While testing on different machines/kernels I noticed some spurious failures resulting from (short) busy-waiting for a /proc/tid/state change in some tests. I added a new TestLib helper method to do the same thing but using the normal test case timeout values and made it do a short sleep instead of having a tight busy-wait loop. frysk-core/frysk/testbed/ChangeLog 2007-08-15 Mark Wielaard * TestLib.java (assertStatState): New static method. * LegacyOffspring.java (assertSendStop): Use TestLib assertStatState(). * SlaveOffspring.java (assertSendStop): Likewise. frysk-core/frysk/proc/ChangeLog 2007-08-15 Mark Wielaard * TestTaskObserverDetach.java (assertDetach): Use TestLib assertStatState(). Please use this method in the future when writing tests that depend on Stat state change detection. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: assert-stat-state.patch Type: text/x-patch Size: 5084 bytes Desc: not available URL: From mark@klomp.org Wed Aug 15 08:54:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 15 Aug 2007 08:54:00 -0000 Subject: frysk-core/frysk gui/ChangeLog stack/RemoteFra ... In-Reply-To: <20070813221141.30722.qmail@sourceware.org> References: <20070813221141.30722.qmail@sourceware.org> Message-ID: <1187168080.3804.23.camel@dijkstra.wildebeest.org> Hi, On Mon, 2007-08-13 at 22:11 +0000, npremji@sourceware.org wrote: > * RemoteFrame.java (getRegisterValue): Check for floating point registers. > Don't throw a null pointer if register can't be located. This is the patch that broke a couple of tests on x86_64. Reverting it makes the tests in frysk.debuginfo.TestFrameDebugInfo and frysk.rt.TestUpdatingDisplayValue that throw NullPointerExceptions PASS again. I suspect that the test for whether or not this is a floating point register fails on x86_64. Could you take a look? Thanks, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: RemoteFrame-nullpointer.diff Type: text/x-patch Size: 1649 bytes Desc: not available URL: From mark@klomp.org Wed Aug 15 11:05:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 15 Aug 2007 11:05:00 -0000 Subject: [patch] breakpoints, stepping and signals Message-ID: <1187175905.3791.17.camel@dijkstra.wildebeest.org> Hi, This patch solves a couple of issues with stepping a breakpoint while a signal becomes pending (in particular bug #4747 and #4889). Most of the patch is the addition of new tests based on funit-raise.S, modeled after funit-symbols.S, that contains several ways of raising an signal from an instruction on which a breakpoint has been put (divde by zero, illegal address, illegal instruction, syscall raising a terminating or ignored signal), this complements some earlier tests written (and now enabled with this patch) that raise an signal externally or through frysk-core (testCodeSignalInterrupt and testInstallCodeDuringCode). When an event interrupts our breakpoint stepping we now abort and reset the Breakpoint if it happened before the step or finish it if it happened after the step before handling the event. The code is pretty conservative in reverting everything related to the breakpoint step setup. This is necessary because we are mostly using reset stepping, so we want to set the breakpoint instruction back quickly, or other tasks that are still running could miss it, and in the case of out of line stepping we currently only have one out of line address available, so we need to return it to the Proc immediately so other tasks can use it (or a new breakpoint in this task is hit through the signal handler for example). frysk-core/frysk/proc/ChangeLog 2007-08-15 Mark Wielaard * getSetupAddress (getSetupAddress): New method. (stepAbort): Likewise. * TestTaskObserverCode.java (testCodeSignalInterrupt): Enable test. (testInstallCodeDuringCode): Likewise. (Symbol): New static helper class. (getGlobalLabelAddress): New helper method. (breakTest): New test harness for funit-raise. (testBreakDivZero): New test based on breakTest. (testBreakIllegalAddress): Likewise. (testBreakIllegalInstruction): Likewise. (testBreakSignalTerminate): Likewise. (testBreakSignalIgnore): Likewise. (AttachedObserver.task): New field. (updateAttached): Set task field. (TerminatingObserver.task): New field. (TerminatingObserver.signal): Likewise. (TerminatingObserver.value): Likewise. (TerminatingObserver.updateTerminating): Set new fields. frysk-core/frysk/proc/live/ChangeLog 2007-08-15 Mark Wielaard * LinuxTaskState.java (Stepping.handleTrappedpEvent): Always check steppingBreakpoint. (checkBreakpointStepping): New helper method. (handleSignaledEvent): Use checkBreakpointStepping before continuing. (handleStoppedEvent): Likewise. frysk-core/frysk/pkglibdir/ChangeLog 2007-08-15 Mark Wielaard * funit-raise.S: New test. Tested on x86_64 kernel 2.6.20 and 2.6.22 (fc6) and x86 kernel 2.6.20-xen and 2.6.22 (f7) both dual core machines. There were no regressions, but there are currently a lot of failures on both architectures which make comparisons of test results somewhat hard. So please let me know if you think this broke something for you. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: breakpoint-signal.patch Type: text/x-patch Size: 16915 bytes Desc: not available URL: From cagney@redhat.com Wed Aug 15 13:20:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 15 Aug 2007 13:20:00 -0000 Subject: meeting 2007-08-15 9:30 us east coast time In-Reply-To: <46C257B2.5030903@redhat.com> References: <46C257B2.5030903@redhat.com> Message-ID: <46C2FDB9.2090800@redhat.com> Since for the last two weeks the round-table fell off the end of the meeting, here's what Red Hat is doing: scox: printing types esp c++ mjw: bug fixes for stepping; support for .debug_frame in libunwind for instance, lesson the need for asynchronous-unwind-tables in .eh_frame by using .debug_frame when available tim: thread commands in hpd for instance: (fhpd) [0,1] print x [0] 10 [1] 20 i.e., prints x in two processes pmuldoon: core file cleanup; low-level h.w watch-point investigation watch-points, like breakpoints, get implemented at two levels: low is the h/w register manipulation and a correspinding abstraction; high is the translation of an expression into something to watch rmoseley: source window crashers (e.g., hover in f7); frysk.proc.dead.Exe* (executable target) this fills in a functional hole, and extends the collection of supported targets, for instance: (fhpd) load /bin/bash (fhpd) disassemble main npremji: hpd option spit 'n' polish a re-implementation of the Command class was added, but unfortunately the old code wasn't upgraded to the new mechanisms mcvet: reporting exit and termination in hpd, ditto for break-points for instance: (fhpd) run ... program exits ... Process 0 exiting with status 1 (fhpd) cmoller: prototype utrace bindings for frysk getting ready for another target frysk.proc.live.Utrace*; would only be enabled with --utrace option. teresa: support for dw_op_piece in location-expressions (a.k.a., frysk.value.Piece) for instance, a value split between registers and memory sami: inline stack backtraces see todays discussion From cagney@redhat.com Wed Aug 15 15:56:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 15 Aug 2007 15:56:00 -0000 Subject: meeting 2007-08-15 9:30 us east coast time In-Reply-To: <46C257B2.5030903@redhat.com> References: <46C257B2.5030903@redhat.com> Message-ID: <46C32222.9030506@redhat.com> Three topis: sami discussing inlined functions; phil/nurdin and corefiles and arguments; what should <> do? Sami: would like to go some use cases involving inlined code and stack frames Here's the code being discussed: sami #include sami inline void third(int arg3){ sami int var3 = arg3; sami int* a = 0; sami a[0] = var3; sami } sami inline void second(int arg2){ sami int var2 = arg2; sami third(var2+1); sami } sami inline void first(int arg1){ sami int var1 = arg1; sami second(var1+1); sami } sami int main(){ sami int some_int = 1; sami first(some_int); sami return 0; sami } and here's the output from the current fstack -a: sami #0 0x0000000000400466 in third(int arg3 = < ERROR >) /to/scratch/swagiaal/frysks/frysk.testBuild/frysk-core/frysk/pkglibdir/funit-inlined.c#6 sami int var3 = < value unavailable at pc=0x400466> line#< error > sami * a = < value unavailable at pc=0x400466> line#< error > sami #1 0x0000000000400466 in second(int arg2 = < optimized out >) /to/scratch/swagiaal/frysks/frysk.testBuild/frysk-core/frysk/pkglibdir/funit-inlined.c#6 sami int var2 = < value unavailable at pc=0x400466> line#< error > sami int var3 = < value unavailable at pc=0x400466> line#< error > sami * a = < value unavailable at pc=0x400466> line#< error > sami #2 0x0000000000400466 in first(int arg1 = < optimized out >) /to/scratch/swagiaal/frysks/frysk.testBuild/frysk-core/frysk/pkglibdir/funit-inlined.c#6 sami int var1 = < value unavailable at pc=0x400466> line#< error > sami int var2 = < value unavailable at pc=0x400466> line#< error > sami int var3 = < value unavailable at pc=0x400466> line#< error > sami * a = < value unavailable at pc=0x400466> line#< error > sami #3 0x0000000000400466 in main () from /tmp/frysks/frysk.testBuild/frysk-core/frysk/pkglibdir/funit>> -- Discussion 1: What output should each "rich" or "inline" frame contain? From inline frame #1 (second): int var2 = < value unavailable at pc=0x400466> line#< error > int var3 = < value unavailable at pc=0x400466> line#< error > * a = < value unavailable at pc=0x400466> line#< error > and notice how it lists variables from both second(var2) and third(var3,a). Should inline frames display just their local variables (reflecting the source) or both their and nested inline scopes (reflecting the DIE information). Long discussion which identified that both dynamic and static information can be displayed: dynamic: given an inline instance, display that instances variables only static: given a function containing inline instances, display the full inline information including scopes created by inlining and the default should be the dynamic info (i.e., inline function display just their local variables) but there be a way to display the static information with additional mark-ups to identify nested inlined functions and their scopes. Discussion #2: What should <<(fhpd) where>> display, should it follow fstack (Side bar, fstack's default is to display just a raw stack using ELF information only so that it is simple and fast; there isn't a good reason for mimicking it). Discussion concluded (fhpd)where should: + include inline functions (performance isn't an issue, full information is) + include function signatures (e.g., String foo(int,boolean)) (lets cut/paste of that for setting breakpoints and easy identification of parameters, but avoids problems of parameter values being wrong) + include file/line (I guess?) - no local variables - no parameters Discussion 3: Commands / options for accessing stack information. Discussion concluded that "where" should broadly follow fstack's option convention; for instance <> and <>. In addition, "info" be extended to include commands to dump out details, for instance <> <> Discussion 4: How should frames be identified. Discussion identified that using simple numbering (#0 #1 #2) for inline frames would lead to frames being identified by different numbers dependant on the presence of inline debug info, and would not help identify inline vs true frames. Its proposed that a Dewey Decimal notation be adopted for instance, using the above: #0.1 third #0.2 second #0.3 first #0 main where there is no nested frame 0 (too confusing over it being either main or third) ---------------------------------- Topic #2 (phil/nurdin) core files needing executables Background: there are times when, to read a corefule, the executable that the core originated from needs to also be supplied. This is due to the core not containing the full path to the executable or that executable path being wrong (e.g., out-of-date). Nurdin explained how the generic command line parser (used by all commands) will recognize <> <> and "just does the right thing". ------------------------------------ Topic #3: what should <> do It was concluded that the answer depends largely on what tool you worked on last; it could bring up either the monitor or the source window. Ignoring the "vote" solution, several options were suggested: - jump to the "session assistant" and, when the process-picker window is displayed have it pre-populated with the list of pids - add --debug | --monitor options From cagney@redhat.com Wed Aug 15 17:52:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 15 Aug 2007 17:52:00 -0000 Subject: meeting 2007-08-15 9:30 us east coast time In-Reply-To: <46C2FDB9.2090800@redhat.com> References: <46C257B2.5030903@redhat.com> <46C2FDB9.2090800@redhat.com> Message-ID: <46C33D4B.2080808@redhat.com> also ... peta: has been using frysk's framework to implement a library tracing tool that works multi-threaded and multi-process me: I've been adding a formatting mechanism (used by the register window, and print) From scox@redhat.com Wed Aug 15 21:02:00 2007 From: scox@redhat.com (Stan Cox) Date: Wed, 15 Aug 2007 21:02:00 -0000 Subject: frysk-core/frysk gui/ChangeLog stack/RemoteFra ... In-Reply-To: <1187168080.3804.23.camel@dijkstra.wildebeest.org> References: <20070813221141.30722.qmail@sourceware.org> <1187168080.3804.23.camel@dijkstra.wildebeest.org> Message-ID: <1187211619.29111.1.camel@multics.rdu.redhat.com> On Wed, 2007-08-15 at 10:54 +0200, Mark Wielaard wrote: > Could you take a look? Thanks for narrowing it down Mark. Guess I'm next in line to look at it. From swagiaal@redhat.com Thu Aug 16 17:30:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Thu, 16 Aug 2007 17:30:00 -0000 Subject: frysk-core/frysk gui/ChangeLog stack/RemoteFra ... In-Reply-To: <1187168080.3804.23.camel@dijkstra.wildebeest.org> References: <20070813221141.30722.qmail@sourceware.org> <1187168080.3804.23.camel@dijkstra.wildebeest.org> Message-ID: <46C489C1.40901@redhat.com> Mark Wielaard wrote: > Hi, > > On Mon, 2007-08-13 at 22:11 +0000, npremji@sourceware.org wrote: > >> * RemoteFrame.java (getRegisterValue): Check for floating point registers. >> Don't throw a null pointer if register can't be located. >> > > This is the patch that broke a couple of tests on x86_64. Reverting it > makes the tests in frysk.debuginfo.TestFrameDebugInfo and > frysk.rt.TestUpdatingDisplayValue that throw NullPointerExceptions PASS > again. > I just committed a fix for this. The problem was that the code only checked for IntType and assumed all else is FloatType. A check for LongType was missing. From pearly.zhao@oracle.com Fri Aug 17 08:47:00 2007 From: pearly.zhao@oracle.com (Zhao Shujing) Date: Fri, 17 Aug 2007 08:47:00 -0000 Subject: [patch] disassembly window Message-ID: <1187340639.3861.47.camel@linux-pzhao.site> Hi This patch is to fix bug #4932 and other bugs of disassembly window. rowPrepend is added to prepend rows by calculating memory information like rowAppend. Because the methods that are provided by class Disassembler, disassembleInstructions and disassembleInstructionsStartEnd, can only read the instructions that are following some address, rowPrepend have to use two while execution control to read the instructions that are preceding some address. Any suggestions are welcomed. --ChangeLog-- 2007-08-17 Zhao Shujing *disassembler/DisassemblyWindow.java: fix bug #4932 (fromBox.entryEvent): Use fromSpin.setValue to invoke fromSpin entryEvent. (toBox.entryEvent): Ditto. (refreshList): Change to get next instruction after finishing model setValue. (rowPrepend): Added. (handleFromSpin): Prepend rows provided by rowPrepend and remove redundant instructions according to the change of memory address. Cheers Pearly -------------- next part -------------- A non-text attachment was scrubbed... Name: disassemblewin.patch Type: text/x-patch Size: 6951 bytes Desc: URL: From pearly.zhao@oracle.com Mon Aug 20 09:07:00 2007 From: pearly.zhao@oracle.com (Zhao Shujing) Date: Mon, 20 Aug 2007 09:07:00 -0000 Subject: [patch] disassembly window In-Reply-To: <1187340639.3861.47.camel@linux-pzhao.site> References: <1187340639.3861.47.camel@linux-pzhao.site> Message-ID: <1187601068.25862.16.camel@linux-pzhao.site> Sorry, I make a mistake with fromBox.entryEvent to use the same code with toBox.entryEvent at the last patch. It is fixed at this one. On Fri, 2007-08-17 at 16:50 +0800, Zhao Shujing wrote: > Hi > > This patch is to fix bug #4932 and other bugs of disassembly window. > rowPrepend is added to prepend rows by calculating memory information > like rowAppend. Because the methods that are provided by class > Disassembler, disassembleInstructions and > disassembleInstructionsStartEnd, can only read the instructions that are > following some address, rowPrepend have to use two while execution > control to read the instructions that are preceding some address. > Any suggestions are welcomed. > > --ChangeLog-- > 2007-08-17 Zhao Shujing > > *disassembler/DisassemblyWindow.java: fix bug #4932 > (fromBox.entryEvent): Use fromSpin.setValue to invoke fromSpin > entryEvent. > (toBox.entryEvent): Ditto. > (refreshList): Change to get next instruction after finishing model > setValue. > (rowPrepend): Added. > (handleFromSpin): Prepend rows provided by rowPrepend and remove > redundant instructions according to the change of memory address. > > > Cheers > Pearly -------------- next part -------------- A non-text attachment was scrubbed... Name: disassemblewin.patch Type: text/x-patch Size: 6920 bytes Desc: URL: From mark@klomp.org Mon Aug 20 09:19:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Mon, 20 Aug 2007 09:19:00 -0000 Subject: test Mercurial repository and Trac instance In-Reply-To: <1186414438.3766.72.camel@dijkstra.wildebeest.org> References: <46AF3DBE.1020802@redhat.com> <46AF7C3A.90509@redhat.com> <46B04E06.7060102@redhat.com> <1186414438.3766.72.camel@dijkstra.wildebeest.org> Message-ID: <1187601575.3785.18.camel@dijkstra.wildebeest.org> Hi, On Mon, 2007-08-06 at 17:33 +0200, Mark Wielaard wrote: > If you want to play with the mercurial repository start with: > hg clone http://gnu.wildebeest.org/hg/frysk > > That is a read-only repository. But be gentle (it is 115MB), that is my > personal machine, it should auto update a few times a day, but no > guarantees that I keep it going. You can however recreate a similar > repository with the attached script and then just put it in some cron > job to periodically update. I played a bit with Trac (http://trac.edgewall.org/) this weekend (http://gnu.wildebeest.org/diary/2007/08/20/bad-memory/) and have now also added a little Trac instance to more easily browse the mercurial source code changesets. Trac is pretty nice and easy to setup (at least on CentOS 5 with EPEL which has all needed packages already). I have disabled all the fancy features (wiki, roadmap, ticketing/bugs system, etc) and only enabled the source browser and source timeline view for the Mercurial mirror. I even tried to theme it a little like the main Frysk site, which was also pretty easy (OK, I mainly just made the background gray and the links blue, I am no CSS wizard). The Mercurial integration into Trac is not 100% yet, and clearly can be optimized a little (read, it is slow). But the result is pretty nice for easily viewing changeset diffs in various ways. Take a look if you like: http://gnu.wildebeest.org/trac/frysk/ Of course everything is readonly and all changes are just automatically generated from the cvs mirroring system (scripts to do it yourself locally are attached to the main Trac page). Cheers, Mark From cagney@redhat.com Mon Aug 20 13:32:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 20 Aug 2007 13:32:00 -0000 Subject: [patch] disassembly window In-Reply-To: <1187340639.3861.47.camel@linux-pzhao.site> References: <1187340639.3861.47.camel@linux-pzhao.site> Message-ID: <46C997F2.1060206@redhat.com> Zhao Shujing wrote: > Hi > > This patch is to fix bug #4932 and other bugs of disassembly window. > rowPrepend is added to prepend rows by calculating memory information > like rowAppend. Because the methods that are provided by class > Disassembler, disassembleInstructions and > disassembleInstructionsStartEnd, can only read the instructions that are > following some address, rowPrepend have to use two while execution > control to read the instructions that are preceding some address. > Any suggestions are welcomed. > Pearly, nice work. The challenge here, and the reason why the disassembler only goes forward from PC is that, in general, it isn't possible to disassemble backwards. This is because architectures such as the i386 and x86-64 have variable length instructions making it effectively impossible to figure out where, looking backwards, an instruction starts. For instance, looking backwards is that a one byte int80 instruction, or a multi-byte instruction loading the hex code for int80? For disassembling a range, can I suggest doing something similar to the disassembler command in frysk.hpd.DisassemblerCommand. That code first attempts to fetch the frysk.symtab.Symbol at the frame's adjusted-address and then uses its address/size to determine the start address and size to disassemble. If the symbol isn't available, then I'd just disassemble a small range from the frame's PC. One heads up for you; you may want to consider configuring your personal build with --with-libopcodes. Andrew From pmuldoon@redhat.com Mon Aug 20 21:28:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Mon, 20 Aug 2007 21:28:00 -0000 Subject: Questions about build web documentation In-Reply-To: <1186950854.3853.29.camel@micmac> References: <1186647756.3865.14.camel@micmac> <1186655070.3747.12.camel@dijkstra.wildebeest.org> <1186950854.3853.29.camel@micmac> Message-ID: <46CA0760.7020906@redhat.com> Thomas Girard wrote: > Thanks for the explanation. > > Please review the attached patch for htdocs/build/index.html. > Apologies for the delay in this. The patch looks fine to me. > I'm wondering if tracker bugs sould be split for Ubuntu and Debian > releases the way they are for Red Hat? > Is there a casual or implied relationship between Ubuntu and Debian that is on-going? Other than Ubuntu was derived from Debian. If not, then they should be treated as different products, with different trackers? My stock opinion here is "whatever is sane for the maintainer". Regards Phil From thomas.g.girard@free.fr Mon Aug 20 22:02:00 2007 From: thomas.g.girard@free.fr (Thomas Girard) Date: Mon, 20 Aug 2007 22:02:00 -0000 Subject: Questions about build web documentation In-Reply-To: <46CA0760.7020906@redhat.com> References: <1186647756.3865.14.camel@micmac> <1186655070.3747.12.camel@dijkstra.wildebeest.org> <1186950854.3853.29.camel@micmac> <46CA0760.7020906@redhat.com> Message-ID: <1187647127.3856.25.camel@micmac> Le lundi 20 ao??t 2007 ?? 16:28 -0500, Phil Muldoon a ??crit : > > I'm wondering if tracker bugs sould be split for Ubuntu and Debian > > releases the way they are for Red Hat? > > Is there a casual or implied relationship between Ubuntu and Debian that > is on-going? Other than Ubuntu was derived from Debian. If not, then > they should be treated as different products, with different trackers? Sorry, my question was misleading: Ubuntu and Debian already have different trackers. But there is a single tracker for all Ubuntu releases, and another single one for all Debian releases. Red Hat on the other hand has a tracker bug for RHEL4, another one for RHEL5. > My stock opinion here is "whatever is sane for the maintainer". I have not yet pushed frysk into sid (it's only available in the experimental Debian repository), so I'll split the Debian tracker bug after that. Thanks, Thomas From mark@klomp.org Tue Aug 21 07:31:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 21 Aug 2007 07:31:00 -0000 Subject: Questions about build web documentation In-Reply-To: <1187647127.3856.25.camel@micmac> References: <1186647756.3865.14.camel@micmac> <1186655070.3747.12.camel@dijkstra.wildebeest.org> <1186950854.3853.29.camel@micmac> <46CA0760.7020906@redhat.com> <1187647127.3856.25.camel@micmac> Message-ID: <1187681465.3852.6.camel@dijkstra.wildebeest.org> Hi Thomas, On Mon, 2007-08-20 at 23:58 +0200, Thomas Girard wrote: > Le lundi 20 ao?t 2007 ? 16:28 -0500, Phil Muldoon a ?crit : > > > I'm wondering if tracker bugs sould be split for Ubuntu and Debian > > > releases the way they are for Red Hat? > > > > Is there a casual or implied relationship between Ubuntu and Debian that > > is on-going? Other than Ubuntu was derived from Debian. If not, then > > they should be treated as different products, with different trackers? > > Sorry, my question was misleading: Ubuntu and Debian already have > different trackers. But there is a single tracker for all Ubuntu > releases, and another single one for all Debian releases. Red Hat on the > other hand has a tracker bug for RHEL4, another one for RHEL5. Yes, and similar for Fedora releases. Since frysk is somewhat dependent on the specific compiler and kernel used it makes sense to have different trackers for distro releases where those components are different. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Tue Aug 21 09:21:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 21 Aug 2007 09:21:00 -0000 Subject: Roundtable, breakpoints and lots of unwinding (Was: meeting 2007-08-15 9:30 us east coast time) In-Reply-To: <46C2FDB9.2090800@redhat.com> References: <46C257B2.5030903@redhat.com> <46C2FDB9.2090800@redhat.com> Message-ID: <1187688075.3852.32.camel@dijkstra.wildebeest.org> Hi Andrew, That was a nice summary and overview of the things people are working on. Thanks. Maybe we can add a wiki somewhere to keep these overviews up to date. Here some additions and details on my current work. > mjw: bug fixes for stepping; Low level stepping of breakpoints in particular. This all started with the demo of TestUpdatingDisplayValue which in the end produced a reproducer for http://sourceware.org/bugzilla/show_bug.cgi?id=4747 Which was just one way of how breakpoint stepping while a signal becomes pending could break. Something which is especially nasty when doing out of line stepping. There is now a low-level instruction stepping test framework: http://sourceware.org/bugzilla/show_bug.cgi?id=4763 http://sourceware.org/ml/frysk/2007-q3/msg00118.html And there is now a low-level test framework for testing signals being raised while breakpoint stepping (except user installed signal handlers for now though): http://sourceware.org/ml/frysk/2007-q3/msg00301.html The work by Petr on fltrace exposed some extra issues, who also helped adding some extra tests, it did take some more time then I had originally though, but I believe with the above the code is a lot more robust and better supports what Petr is doing. In particular the following bugs have now been closed: http://sourceware.org/bugzilla/show_bug.cgi?id=4889 http://sourceware.org/bugzilla/show_bug.cgi?id=4894 There are still 3 issues I know of with low-level stepping of breakpoints (none of which I am currently actively working on, but I expect fltrace to hit them, so when that work is progressing we might want to go back to these issues): http://sourceware.org/bugzilla/show_bug.cgi?id=4847 Stepping Trap instructions (in particular inside a trap signal handler) is broken (again) on newer kernels. Getting stepping of a trap instruction and stepping of the trap handler needs to be fully special cased. And the kernel doesn't help because it changes behavior every other release it seems. Not working on this till someone finds a real use case for this one. http://sourceware.org/bugzilla/show_bug.cgi?id=4762 We don't have a real Instruction parser (x86/x86_64) for single stepping out of line framework (see IA32InstructionParser) which means that for almost all instructions we are actually using reset breakpoint stepping which misses breakpoints when used with multiple threads. Not currently working on this one either, but I suspect that the new fltrace work that Petr is doing will soon hit this limitation at which time we should either finish the instruction parser or introduce stop-the-world stepping to make things more robust. http://sourceware.org/bugzilla/show_bug.cgi?id=4895 Low level breakpoints are visible to all Tasks, not just the Task that requested it. This seemed to be a good idea back when they were added since low-level breakpoints are essentially Proc based, but this confuses some users because they have to check the Task argument in their updateHit() handler, the workaround is easy, so not very important, but it would be better if this was cleaned up. > support for .debug_frame in libunwind > for instance, lesson the need for asynchronous-unwind-tables in > .eh_frame by using .debug_frame when available The breakpoints took some more time than I had anticipated, so I am still working on this bit. Since there is a lot of layers to unwinding and documentation is scattered all over the place here is a summary of unwinding as I found it. Both to document my own research and to structure the work a bit. If any of the below is wrong, please let me know. Unwinding the call stack used to be something only a debugger would do and relied on the executable having a frame pointer in a dedicated register that points to the bottom of the stack frame for the current function which also contained the return address [1]. Having a frame pointer allows you to quickly walk the call stack and get all the addresses, if you can map those to the names of the relevant functions they are in you have a nice backtrace for the user. If you want to get more of the state then you could rely on each function having a prologue and epilogue that saved and restored the registers [2] of the caller. Given a calling convention for a particular architecture you could use these to reliably find the original registers on the stack, which in turn with some debug info would give you the values of variables and arguments of the functions on the call stack. Unfortunately compilers got smart and optimized code might not keep a frame pointer (frees up one more register) and might reschedule the function prologue and epilogue instructions between the other instructions in the function. All making it pretty hard for an unwinder to reconstruct the previous call frames on the stack. In particular x86_64 does away with a standard frame pointer. You can still get some information back by conservatively approximating the instructions in the function and guessing at the actual way the various registers are stored [3] but this becomes pretty messy pretty quickly. To help debuggers still get all the information needed to unwind a stack and restore all needed registers the debugging information (DWARF) generated by compilers was extended to include Call Frame Information (CFI) [4] that allows a debugger to reconstruct the the calling pc and registers of a function. This information is stored in the .debug_frame section of an elf file. It uses a simplified version of the dwarf instructions (not all operands are relevant for reconstructing the registers). This section is not guaranteed to be available, it is not necessarily loaded into memory and can even be split off into its own debug info file in some distributions. At the same time different languages got constructs (exceptions, continuations, global gotos, asynchronous garbage collectors, etc) which required some sort of reliable unwinding (and in some cases rewinding) of the call stack. Since some optimizations and some newer architectures also did away with a standard frame pointer another way to reliably unwind the stack was needed. This became the exception handler framework (eh_frame) which is based on the DWARF CFI work but which is slightly different. Unfortunately nobody seems to have documented the precise differences between the formats. So you will have to carefully read both the DWARF standard and the LSB core specification Exception Frames [5] side-by-side. Note that a debugger that wants to walk a stack and recover all registers might need more information than some of these language constructs which might only need unwind information for specific call sites. Depending on optimizations, architecture and language compiled (and sometimes specific distribution default choices) no, full or partial exception handler unwind information and/or frame pointers are generated (see the GCC options -funwind-tables and -fasynchronous-unwind-tables [6]). Both the dwarf and the exception handler specs are architecture neutral. But since you do need to a mapping between the actual registers and the specs you also need to consult the relevant architecture abi that defines the actual mapping. Sometimes these architecture abi specs also define some DWARF/EH extensions. See for example the x86_64 abi spec [7]. Note that in practise what gcc generates overrides any of the above specs, and if a discrepancy is found the spec usually gets updated [8]. And that one should be careful about bugs in the old DWARF2 spec [9] and extension of DWARF specified by the LSB [10] (which mostly augment DWARF2 to be like DWARF3, at least for the exception handler sections). If an .eh_frame section is available in an elf file it is guaranteed to be loaded in memory. But depending on architecture and language being compiled might not be available at all (and neither might the frame pointer or the .debug_frame section). So with that background the work having to be done consists of the following: - libunwind officially only supports the .eh_frame format so it will have to be extended to also support the .debug_frame format. Luckily the differences, although very poorly documented, don't seem to be that large. - libunwind has its own CFI EH/DWARF parser but doesn't come with an interface to feed/read the CFI information directly. This is the Gget_unwind_table.c (unw_get_unwind_table) support that Nurdin added, but which isn't upstream yet. Pushing this upstream would be very beneficial since then we could use pure upstream in frysk, but see the next point, maybe the proposed interface should be changed a little. - Currently we hook into this new unw_get_unwind_table through UnwindH.hxx (createProcInfoFromElfImage), this is called indirectly through the libunwind find_proc_info callback which wants to see the unwind_info filled in. The ElfImage used is created in UnwindAddressSpace.findProcInfo() through the private method getElfImage(long address) by getting the MemoryMap of the address from the Task and either mapping the map from the elf file into memory or if the section is the VDSO by creating an anonymous mmap and filling that through reading the address map and then passing it to the libunwind dwarf reader. Directly mmapping these sections seems wrong here since the sections should already be available through the memory buffers of the proc we are inspecting (which might already have mapped in those sections). So it would be better to use the libunwind addressspace accessors that go through the ByteBuffers also for this. This might mean another change in the libunwind interface so all remote memory accesses go through the same hooks (although unw_get_unwind_table already provides an unw_address_space as argument, so I might be missing something). - For the .debug_info we cannot rely on it being available in the target address space (unlike .eh_frame which always gets loaded) and it might not be in the elf file directly, but might be in a separate debuginfo file. So there we need to locate the section first through libdwfl, load it (also through libdwfl?) and feed that to libunwind. Cheers, Mark [1] http://en.wikipedia.org/wiki/Frame_pointer [2] http://en.wikipedia.org/wiki/Function_prologue [3] http://sourceware.org/gdb/current/onlinedocs/gdbint_3.html#SEC9 [4] http://wiki.dwarfstd.org/ (Dwarf 3 - section 6.4) [5] http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html [6] http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html [7] http://www.x86-64.org/documentation/abi.pdf (Section 3.6 and 3.7) [8] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32982 [9] http://wiki.dwarfstd.org/index.php?title=DWARF_FAQ#How_big_is_a_DW_FORM_ref_addr.3F [10] http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/dwarfext.html From kris.van.hees@oracle.com Tue Aug 21 12:44:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Tue, 21 Aug 2007 12:44:00 -0000 Subject: Automated build-and-test summary report (2007/08/21) In-Reply-To: <20070821123204.GA10162@oracle.com> References: <20070821123204.GA10162@oracle.com> Message-ID: <20070821124331.GA10126@oracle.com> As shown below, we had another case of a commit blocking the build last night. As usual, Mark was able to fix this due to his timezone advantage. Thanks, Mark! Could I make the suggestion that we *all* do test builds before doing a commit (building the exact state of the tree as it is being commited), to ensure we do not keep running into these problems? I remember that when I joined Frysk, testing before a commit was stated to be the rule. I hope that has not changed? Cheers, Kris On Tue, Aug 21, 2007 at 08:32:04AM -0400, Kris Van Hees wrote: > For more detailed results, please check out the reports at: > > http://build.alchar.org/~aedil/rep/ > > ------------------------------------------------------------------------------ > Package: frysk_fresh > Previous build: 2007/08/20 03:53:12 - 2007/08/20 16:12:31 > Current build: 2007/08/21 03:47:40 - 2007/08/21 04:07:00 > Host: coldstone > Platform: Linux x86_64 2.6.20-1.2962.fc6 (FC6) > URL http://build.alchar.org/~aedil/rep/coldstone/frysk_fresh.20070821-034740.html > First failure: build (was test) > > ------------------------------------------------------------------------------ > Package: frysk_incr > Previous build: 2007/08/20 03:34:02 - 2007/08/20 03:53:00 > Current build: 2007/08/21 03:34:03 - 2007/08/21 03:47:29 > Host: coldstone > Platform: Linux x86_64 2.6.20-1.2962.fc6 (FC6) > URL http://build.alchar.org/~aedil/rep/coldstone/frysk_incr.20070821-033403.html > First failure: build (was test) > > ------------------------------------------------------------------------------ > Package: frysk_fresh > Previous build: 2007/08/20 02:03:19 - 2007/08/20 02:23:18 > Current build: 2007/08/21 02:02:56 - 2007/08/21 02:21:06 > Host: ca-tools2 > Platform: Linux i386 2.6.20-1.2962.fc6 (FC6) > URL http://build.alchar.org/~aedil/rep/ca-tools2/frysk_fresh.20070821-020256.html > First failure: test > Test result: 822: 742 +, 31 -, 16 S, 33 E (was 822: 744 +, 31 -, 14 S, 33 E) > > Old -> New Test > ----- ----- ---------------------------------- > PASS -> N/A frysk-core - testArrayOfNumber(frysk.value.TestValue) > PASS -> ERROR frysk-sys - testLeakyPipes(frysk.sys.TestLeakingFileDescriptor) > N/A -> PASS frysk-core - testArrayOfNumber(frysk.value.TestArray) > N/A -> PASS frysk-core - testEnumInt(frysk.value.TestEnum) > PASS -> N/A frysk-core - testArrayOfArrayOfNumber(frysk.value.TestValue) > N/A -> PASS frysk-core - testArrayOfArrayOfNumber(frysk.value.TestArray) > PASS -> N/A frysk-core - testEnum(frysk.value.TestValue) > PASS -> ERROR frysk-sys - testDataValPeekBytes(frysk.sys.TestPtrace) > N/A -> PASS frysk-core - testEnum(frysk.value.TestEnum) > N/A -> PASS frysk-core - testSlice(frysk.value.TestLocation) > N/A -> PASS frysk-core - testEnumType(frysk.value.TestEnum) > > ------------------------------------------------------------------------------ > Package: frysk_incr > Previous build: 2007/08/20 01:45:02 - 2007/08/20 02:03:17 > Current build: 2007/08/21 01:45:01 - 2007/08/21 02:02:55 > Host: ca-tools2 > Platform: Linux i386 2.6.20-1.2962.fc6 (FC6) > URL http://build.alchar.org/~aedil/rep/ca-tools2/frysk_incr.20070821-014501.html > First failure: test > Test result: 801: 730 +, 31 -, 7 S, 33 E (was 798: 727 +, 31 -, 6 S, 34 E) > > Old -> New Test > ----- ----- ---------------------------------- > PASS -> N/A frysk-core - testArrayOfNumber(frysk.value.TestValue) > PASS -> ERROR frysk-sys - testLeakyPipes(frysk.sys.TestLeakingFileDescriptor) > N/A -> PASS frysk-core - testArrayOfNumber(frysk.value.TestArray) > N/A -> PASS frysk-core - testEnumInt(frysk.value.TestEnum) > PASS -> N/A frysk-core - testArrayOfArrayOfNumber(frysk.value.TestValue) > N/A -> PASS frysk-core - testArrayOfArrayOfNumber(frysk.value.TestArray) > PASS -> N/A frysk-core - testEnum(frysk.value.TestValue) > ERROR -> PASS frysk-core - testRegsCommand(frysk.hpd.TestRegs) > N/A -> PASS frysk-core - testEnum(frysk.value.TestEnum) > N/A -> PASS frysk-core - testSlice(frysk.value.TestLocation) > N/A -> PASS frysk-core - testEnumType(frysk.value.TestEnum) From cagney@redhat.com Tue Aug 21 20:50:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 21 Aug 2007 20:50:00 -0000 Subject: frysk meeting 2007-08-22? Message-ID: <46CB5018.9070000@redhat.com> From last week; as many from Red Hat will be away I wasn't planning on there being a meeting this week. However the lines are still available. Andrew From pearly.zhao@oracle.com Wed Aug 22 09:14:00 2007 From: pearly.zhao@oracle.com (Zhao Shujing) Date: Wed, 22 Aug 2007 09:14:00 -0000 Subject: [patch] disassembly window In-Reply-To: <46C997F2.1060206@redhat.com> References: <1187340639.3861.47.camel@linux-pzhao.site> <46C997F2.1060206@redhat.com> Message-ID: <1187774326.4163.16.camel@linux-pzhao.site> Hi, Andrew Thanks for the explanation of disassemble backwards. If the symbol isn't available, gdb's disassemble command would return "No function contains specified address". Would frysk's disassemble command disassemble a small range from the frame's PC, not just return some warning sentence? Thanks Pearly On Mon, 2007-08-20 at 09:32 -0400, Andrew Cagney wrote: > Zhao Shujing wrote: > > Hi > > > > This patch is to fix bug #4932 and other bugs of disassembly window. > > rowPrepend is added to prepend rows by calculating memory information > > like rowAppend. Because the methods that are provided by class > > Disassembler, disassembleInstructions and > > disassembleInstructionsStartEnd, can only read the instructions that are > > following some address, rowPrepend have to use two while execution > > control to read the instructions that are preceding some address. > > Any suggestions are welcomed. > > > > Pearly, nice work. > > The challenge here, and the reason why the disassembler only goes > forward from PC is that, in general, it isn't possible to disassemble > backwards. This is because architectures such as the i386 and x86-64 > have variable length instructions making it effectively impossible to > figure out where, looking backwards, an instruction starts. For > instance, looking backwards is that a one byte int80 instruction, or a > multi-byte instruction loading the hex code for int80? > > For disassembling a range, can I suggest doing something similar to the > disassembler command in frysk.hpd.DisassemblerCommand. That code first > attempts to fetch the frysk.symtab.Symbol at the frame's > adjusted-address and then uses its address/size to determine the start > address and size to disassemble. If the symbol isn't available, then > I'd just disassemble a small range from the frame's PC. > > One heads up for you; you may want to consider configuring your personal > build with --with-libopcodes. > > Andrew > From mark@klomp.org Wed Aug 22 12:26:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 22 Aug 2007 12:26:00 -0000 Subject: Disassembly source buffer and libopcodes Message-ID: <1187785589.3759.10.camel@dijkstra.wildebeest.org> Hi, Since Fedora did a license audit and found we were linking in libopcodes from binutils which is under GPL, but we distribute Frysk under GPL + Exception, automatic libopcode usage has been disabled (you need to configure --with-libopcodes to get it). But this exposed a bug in SourceBuffer which didn't handle not getting any disassembly. This patch fixes that (and makes the method slightly more efficient by using only one StringBuilder and appending the chars individually, not as String objects). And it fixes a typo in Disassembler.cxx which prevented disassembly even when --with-libopcodes was given. frysk-gui/frysk/gui/srcwin/ChangeLog 2007-08-22 Mark Wielaard * SourceBuffer.java (disassembleFrame): Use one StringBuffer, only call Iterator.next() when hasNext() returns true, append chars individually, not as String objects. frysk-sys/lib/opcodes/ChangeLog 2007-08-22 Mark Wielaard * cni/Disassembler.cxx (disassemble): Use WITH_LIBOPCODES, not HAVE_LIPOPCODES. This fixes bug #4948. Tested with and without --with-libopcodes. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: Disassembler.patch Type: text/x-patch Size: 2230 bytes Desc: not available URL: From cagney@redhat.com Wed Aug 22 13:09:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 22 Aug 2007 13:09:00 -0000 Subject: [patch] disassembly window In-Reply-To: <1187774326.4163.16.camel@linux-pzhao.site> References: <1187340639.3861.47.camel@linux-pzhao.site> <46C997F2.1060206@redhat.com> <1187774326.4163.16.camel@linux-pzhao.site> Message-ID: <46CC356C.30300@redhat.com> Zhao Shujing wrote: > Hi, Andrew > Thanks for the explanation of disassemble backwards. > > If the symbol isn't available, gdb's disassemble command would return > "No function contains specified address". Would frysk's disassemble > command disassemble a small range from the frame's PC, not just return > some warning sentence? > Pearly, yes, the command-line will still disassemble. And I like the idea of the disassembler-window can do something similar. Andrew > Thanks > Pearly > On Mon, 2007-08-20 at 09:32 -0400, Andrew Cagney wrote: > >> Zhao Shujing wrote: >> >>> Hi >>> >>> This patch is to fix bug #4932 and other bugs of disassembly window. >>> rowPrepend is added to prepend rows by calculating memory information >>> like rowAppend. Because the methods that are provided by class >>> Disassembler, disassembleInstructions and >>> disassembleInstructionsStartEnd, can only read the instructions that are >>> following some address, rowPrepend have to use two while execution >>> control to read the instructions that are preceding some address. >>> Any suggestions are welcomed. >>> >>> >> Pearly, nice work. >> >> The challenge here, and the reason why the disassembler only goes >> forward from PC is that, in general, it isn't possible to disassemble >> backwards. This is because architectures such as the i386 and x86-64 >> have variable length instructions making it effectively impossible to >> figure out where, looking backwards, an instruction starts. For >> instance, looking backwards is that a one byte int80 instruction, or a >> multi-byte instruction loading the hex code for int80? >> >> For disassembling a range, can I suggest doing something similar to the >> disassembler command in frysk.hpd.DisassemblerCommand. That code first >> attempts to fetch the frysk.symtab.Symbol at the frame's >> adjusted-address and then uses its address/size to determine the start >> address and size to disassemble. If the symbol isn't available, then >> I'd just disassemble a small range from the frame's PC. >> >> One heads up for you; you may want to consider configuring your personal >> build with --with-libopcodes. >> >> Andrew >> >> > > > From elena.zannoni@oracle.com Wed Aug 22 14:27:00 2007 From: elena.zannoni@oracle.com (Elena Zannoni) Date: Wed, 22 Aug 2007 14:27:00 -0000 Subject: Disassembly source buffer and libopcodes In-Reply-To: <1187785589.3759.10.camel@dijkstra.wildebeest.org> References: <1187785589.3759.10.camel@dijkstra.wildebeest.org> Message-ID: <46CC476F.7000106@oracle.com> Mark Wielaard wrote: > Hi, > > Since Fedora did a license audit and found we were linking in libopcodes > from binutils which is under GPL, but we distribute Frysk under GPL + > Exception, automatic libopcode usage has been disabled (you need to > configure --with-libopcodes to get it). Thanks for discussing this on the mailing list, can you explain a bit more about it? I wasn't aware of the audit, is this a RH thing? or a fedora thing? Does it impact frysk in other ways? I assume this is reason for the change Andrew made on August 16? http://sourceware.org/ml/frysk-cvs/2007-q3/msg00648.html Is there any public discussion of the audit? thanks elena From mark@klomp.org Wed Aug 22 14:51:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 22 Aug 2007 14:51:00 -0000 Subject: Disassembly source buffer and libopcodes In-Reply-To: <46CC476F.7000106@oracle.com> References: <1187785589.3759.10.camel@dijkstra.wildebeest.org> <46CC476F.7000106@oracle.com> Message-ID: <1187794289.3759.20.camel@dijkstra.wildebeest.org> Hi Elena, On Wed, 2007-08-22 at 10:25 -0400, Elena Zannoni wrote: > > Since Fedora did a license audit and found we were linking in libopcodes > > from binutils which is under GPL, but we distribute Frysk under GPL + > > Exception, automatic libopcode usage has been disabled (you need to > > configure --with-libopcodes to get it). > > Thanks for discussing this on the mailing list, can you explain a bit > more about it? > I wasn't aware of the audit, is this a RH thing? or a fedora thing? Does > it impact frysk in other ways? It is a Fedora thing. They are cleaning up the package license tags: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag This means all packages are audited now. The main Frysk license is GPL + Exception so we can link with non-gpl compatible code like eclipse. One of the maintainers noticed that we were using binutils (libopcodes) which is GPL-only though, so cannot be used in a larger work with EPL code. > I assume this is reason for the change Andrew made on > August 16? > http://sourceware.org/ml/frysk-cvs/2007-q3/msg00648.html > > Is there any public discussion of the audit? fedora-devel and fedora-maintainers has lots, but those are super busy lists: http://www.redhat.com/mailman/listinfo/fedora-devel-list https://www.redhat.com/archives/fedora-maintainers/ This particular issue came up here first I believe: https://www.redhat.com/archives/fedora-maintainers/2007-August/msg00264.html Cheers, Mark From pmuldoon@redhat.com Wed Aug 22 15:11:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Wed, 22 Aug 2007 15:11:00 -0000 Subject: frysk-core/frysk/proc Breakpoint.java IsaIA32. ... In-Reply-To: <20070115134847.31787.qmail@sourceware.org> References: <20070115134847.31787.qmail@sourceware.org> Message-ID: <46CC5226.8040607@redhat.com> mark@sourceware.org wrote: > CVSROOT: /cvs/frysk > Module name: frysk-core > Changes by: mark@sourceware.org 2007-01-15 13:48:47 > > Modified files: > frysk/proc : Breakpoint.java IsaIA32.java IsaX8664.java > LinuxIa32On64.java LinuxPtraceTaskState.java > TestTaskObserverInstruction.java > TestTaskObserverInstructionAndCode.java > > Log message: > Fixes bug #3676 > * Breakpoint.java (stepDone): Only set if still installed. > (isInstalled): new method. > (toString): Prettify. > * IsaIA32.java (isTaskStepped): Reset flag. > * IsaX8664.java (isTaskStepped): Likewise. > Mark, As we talked about on irc, and in addition to looking at this code in preparation for hardware watchpoints, can I make a small recommendation here? isTaskStepped(task) is a query, and should imo not be altering any debug registers after the fact. Can I propose a split into: isTaskStepped(task) and setTaskStepped(task) Does that make better sense? Regards Phil From elena.zannoni@oracle.com Wed Aug 22 16:02:00 2007 From: elena.zannoni@oracle.com (Elena Zannoni) Date: Wed, 22 Aug 2007 16:02:00 -0000 Subject: Disassembly source buffer and libopcodes In-Reply-To: <1187794289.3759.20.camel@dijkstra.wildebeest.org> References: <1187785589.3759.10.camel@dijkstra.wildebeest.org> <46CC476F.7000106@oracle.com> <1187794289.3759.20.camel@dijkstra.wildebeest.org> Message-ID: <46CC5DF2.6060909@oracle.com> Mark Wielaard wrote: > Hi Elena, > > On Wed, 2007-08-22 at 10:25 -0400, Elena Zannoni wrote: > >>> Since Fedora did a license audit and found we were linking in libopcodes >>> from binutils which is under GPL, but we distribute Frysk under GPL + >>> Exception, automatic libopcode usage has been disabled (you need to >>> configure --with-libopcodes to get it). >>> >> Thanks for discussing this on the mailing list, can you explain a bit >> more about it? >> I wasn't aware of the audit, is this a RH thing? or a fedora thing? Does >> it impact frysk in other ways? >> > > It is a Fedora thing. They are cleaning up the package license tags: > http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > This means all packages are audited now. The main Frysk license is GPL + > Exception so we can link with non-gpl compatible code like eclipse. One > of the maintainers noticed that we were using binutils (libopcodes) > which is GPL-only though, so cannot be used in a larger work with EPL > code. > > >> I assume this is reason for the change Andrew made on >> August 16? >> http://sourceware.org/ml/frysk-cvs/2007-q3/msg00648.html >> >> Is there any public discussion of the audit? >> > > fedora-devel and fedora-maintainers has lots, but those are super busy > lists: http://www.redhat.com/mailman/listinfo/fedora-devel-list > https://www.redhat.com/archives/fedora-maintainers/ > > This particular issue came up here first I believe: > https://www.redhat.com/archives/fedora-maintainers/2007-August/msg00264.html > > Cheers, > > Mark > > Thanks, I see Andrew replied to that thread, so what is the impact on frysk? Do we switch to GPLv3 or just ignore since we have our copy of libopcodes (and keep that at GPLv2?) From mark@klomp.org Wed Aug 22 18:08:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 22 Aug 2007 18:08:00 -0000 Subject: frysk-core/frysk/proc Breakpoint.java IsaIA32. ... In-Reply-To: <46CC5226.8040607@redhat.com> References: <20070115134847.31787.qmail@sourceware.org> <46CC5226.8040607@redhat.com> Message-ID: <1187806056.3759.27.camel@dijkstra.wildebeest.org> Hi Phil, On Wed, 2007-08-22 at 10:11 -0500, Phil Muldoon wrote: > > Fixes bug #3676 > > * Breakpoint.java (stepDone): Only set if still installed. > > (isInstalled): new method. > > (toString): Prettify. > > * IsaIA32.java (isTaskStepped): Reset flag. > > * IsaX8664.java (isTaskStepped): Likewise. > > > As we talked about on irc, and in addition to looking at this code in > preparation for hardware watchpoints, can I make a small recommendation > here? > > isTaskStepped(task) is a query, and should imo not be altering any debug > registers after the fact. > > Can I propose a split into: > > isTaskStepped(task) and setTaskStepped(task) > > Does that make better sense? That does make sense. Although I don't know if someone really needs setTaskStepped(), so I wouldn't introduce it unless there was a real usage for it. The reason why the flag is reset here is mentioned in the original patch email: http://sourceware.org/ml/frysk/2007-q1/msg00024.html > There is one thing that changed in the semantics of Isa.isTaskStepped() > for x86 and x86_64 (and Ia32On64 has been added). That is that the > stepping flag in the d6 register is being reset because "[the d6] > register is never cleared by the processor and must be cleared by > software after the contents have been read". This means that we are now > doing a inferior visible change, but I don't see any way to get around > this. If the inferior would be using instruction stepping itself there > would be all kinds of interesting issues anyway. I do agree this might not be the most ideal place to reset this flag though. Maybe it should be moved into LinuxTask.sendContinue()? Cheers, Mark From mark@klomp.org Wed Aug 22 18:13:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 22 Aug 2007 18:13:00 -0000 Subject: Disassembly source buffer and libopcodes In-Reply-To: <46CC5DF2.6060909@oracle.com> References: <1187785589.3759.10.camel@dijkstra.wildebeest.org> <46CC476F.7000106@oracle.com> <1187794289.3759.20.camel@dijkstra.wildebeest.org> <46CC5DF2.6060909@oracle.com> Message-ID: <1187806402.3759.34.camel@dijkstra.wildebeest.org> Hi Elena, On Wed, 2007-08-22 at 12:01 -0400, Elena Zannoni wrote: > Thanks, I see Andrew replied to that thread, so what is the impact on > frysk? > Do we switch to GPLv3 or just ignore since we have our copy of > libopcodes (and keep that at GPLv2?) Unfortunately neither is an option atm :{ We have one other GPLv2-only dependency elfutils. elfutils does have the same special exception for linking it with eclipse code into a larger work as frysk has, but binutils/libopcodes is GPL-only and unfortunately the EPL isn't GPL compatible (neither with version 2 nor version 3). So we have to either ditch the EPL eclipse code (so the exception isn't needed and we can just use pure GPL), ask the Eclipse people to dual license under the GPL, or find an disassembler that is compatible with both the GPL and EPL code. Cheers, Mark From pmuldoon@redhat.com Wed Aug 22 21:33:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Wed, 22 Aug 2007 21:33:00 -0000 Subject: Make CoredumpAction use Task.getRegisterBanks() In-Reply-To: <1186043315.15044.46.camel@dijkstra.wildebeest.org> References: <1185814384.3674.36.camel@dijkstra.wildebeest.org> <46AE238B.5020204@redhat.com> <1185883408.3653.106.camel@dijkstra.wildebeest.org> <46AFD351.6030004@redhat.com> <1186043315.15044.46.camel@dijkstra.wildebeest.org> Message-ID: <46CCAB8B.5000202@redhat.com> Mark Wielaard wrote: >> I think, going forward access to the raw memory for each register bank, >> and also a getRegisterByName() function (which is the functionality we >> have now) is needed, and probably will be down the line. >> > > If we can match up the raw memory for each register bank between > ptrace/proc and core files from Task that would be ideal. Then the Isa > can just do the getRegisterByName() mapping. I'll watch your rewrite of > the core file stuff and see if this makes things easier and clearer (I > guess it will). > > Now that all the register stuff is in, lets open this up again. In a corefile there are 3 sets of registers written for x86: General Purpose (GP) Registers Floating Point Registers (FP) eXtended Floating Point (XFP) Registers The first, GP Registers are written as part of a Elf prStatus note. One per thread. Because these registers are part of "another" struct, and do not have a note all to themselves, they have to be read one by one, sorted, then written into the structure along with other prStatus data (tid, and so on). Both FP and XFP both have their own note types and can be written wholesale as a bytebuffer to the corefile. No interpretation needed. Whether raw register memory access belongs in the ISA, the Task is not really important from a corefile view, though I would like to see it consistent. Regards Phil From pmuldoon@redhat.com Wed Aug 22 21:43:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Wed, 22 Aug 2007 21:43:00 -0000 Subject: Roundtable, breakpoints and lots of unwinding (Was: meeting 2007-08-15 9:30 us east coast time) In-Reply-To: <1187688075.3852.32.camel@dijkstra.wildebeest.org> References: <46C257B2.5030903@redhat.com> <46C2FDB9.2090800@redhat.com> <1187688075.3852.32.camel@dijkstra.wildebeest.org> Message-ID: <46CCADFB.40407@redhat.com> Mark Wielaard wrote: >> mjw: bug fixes for stepping; >> > > - Currently we hook into this new unw_get_unwind_table through > UnwindH.hxx (createProcInfoFromElfImage), this is called indirectly > through the libunwind find_proc_info callback which wants to see the > unwind_info filled in. The ElfImage used is created in > UnwindAddressSpace.findProcInfo() through the private method > getElfImage(long address) by getting the MemoryMap of the address from > the Task and either mapping the map from the elf file into memory or if > the section is the VDSO by creating an anonymous mmap and filling that > through reading the address map and then passing it to the libunwind > dwarf reader. Directly mmapping these sections seems wrong here since > the sections should already be available through the memory buffers of > the proc we are inspecting (which might already have mapped in those > sections). So it would be better to use the libunwind addressspace > accessors that go through the ByteBuffers also for this. This might mean > another change in the libunwind interface so all remote memory accesses > go through the same hooks (although unw_get_unwind_table already > provides an unw_address_space as argument, so I might be missing > something). > > This strikes me as especially worry-some in core file unwinding. Why would you want to mmap at all anything? All access to any memroy/maps in a core file case should be done via .getMemory(). It should be left to the CorefileByteBuffer to arbitrate whether it can find the memory address in the core file and return that, or go to the relevant solib and get it for you. It is the only thing that has the sufficient meta-data, and thus smarts to make that decision. Maybe I misunderstood, but other than the initial "beginning" of the unwind, the unwind code might be mmap'ing the library in directly? Nice write up, by the way. This is ideal blogging material. Regards Phil From swagiaal@redhat.com Wed Aug 22 21:45:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Wed, 22 Aug 2007 21:45:00 -0000 Subject: elfutils import Message-ID: <46CCAE6A.3000904@redhat.com> I have tagged the frysk source with: pre-elfutils_0_129-merge Imported elfutils 0.129 under the branch: elfutils_0_129 But have not merged it with the main trunk yet, as there are some test failures. To get a merged version of the tree I do this: cvs -d:ext:swagiaal@sources.redhat.com:/cvs/frysk checkout -j elfutils_0_127 -j elfutils_0_129 frysk I then resolve all the conflicts by blindly favoring upstream. From pmuldoon@redhat.com Wed Aug 22 21:47:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Wed, 22 Aug 2007 21:47:00 -0000 Subject: frysk-core/frysk/proc Breakpoint.java IsaIA32. ... In-Reply-To: <1187806056.3759.27.camel@dijkstra.wildebeest.org> References: <20070115134847.31787.qmail@sourceware.org> <46CC5226.8040607@redhat.com> <1187806056.3759.27.camel@dijkstra.wildebeest.org> Message-ID: <46CCAEF9.4030504@redhat.com> Mark Wielaard wrote: > I do agree this might not be the most ideal place to reset this flag > though. Maybe it should be moved into LinuxTask.sendContinue()? > > > Not sure where, but hopefully somewhere better than an a query function. Regards Phil From roland@redhat.com Wed Aug 22 21:52:00 2007 From: roland@redhat.com (Roland McGrath) Date: Wed, 22 Aug 2007 21:52:00 -0000 Subject: elfutils import In-Reply-To: Sami Wagiaalla's message of Wednesday, 22 August 2007 17:45:14 -0400 <46CCAE6A.3000904@redhat.com> Message-ID: <20070822215158.AFB804D0418@magilla.localdomain> > But have not merged it with the main trunk yet, as there are some test > failures. There is one self-test failure on F8 for ppc32 with the 0.129 sources. Rawhide has a patch for that. > I then resolve all the conflicts by blindly favoring upstream. Please show me all the differences in that tree from the upstream elfutils. You should not be carrying any. Thanks, Roland From pmuldoon@redhat.com Thu Aug 23 00:24:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 23 Aug 2007 00:24:00 -0000 Subject: Extending Frysk to trace user-space lockings In-Reply-To: <1184921481.3611.17.camel@dijkstra.wildebeest.org> References: <46A02732.3090900@redhat.com> <1184921481.3611.17.camel@dijkstra.wildebeest.org> Message-ID: <46CCD3AB.8060700@redhat.com> Mark Wielaard wrote: > Hi Eugene, > > On Fri, 2007-07-20 at 11:08 +0800, Eugene Teo wrote: > >> Is it possible to extend Frysk to trace user-space lockings? I am trying to >> write a tool that basically outputs the lock used and the backtrace showing >> who is holding on to it. I don't really have an example output that I can show, >> but if you have an idea to share, do let me know! >> > > I am afraid I know too little about user space locking or even know how > various user space locking mechanisms are implemented to give a real > answer. > > Lets assume you are interested in pthread mutexes. Are futex's exposed via fhpd at the moment? Regards Phil From pmuldoon@redhat.com Thu Aug 23 00:45:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 23 Aug 2007 00:45:00 -0000 Subject: Extending Frysk to trace user-space lockings In-Reply-To: <46CCD3AB.8060700@redhat.com> References: <46A02732.3090900@redhat.com> <1184921481.3611.17.camel@dijkstra.wildebeest.org> <46CCD3AB.8060700@redhat.com> Message-ID: <46CCD8A9.6050304@redhat.com> Phil Muldoon wrote: > > Are futex's exposed via fhpd at the moment? > Answering self, no. But: *./frysk_bin/frysk-core/frysk/bindir/ftrace -p 5396 -t futex *Should trace all futex calls in the process. In that example, 5396 was firefox which makes lots of use of them. Does this help a bit in your task, Eugene? Regards Phil From cagney@redhat.com Thu Aug 23 14:35:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 23 Aug 2007 14:35:00 -0000 Subject: Value.toPrint(PrintWriter, ...) and Type.toPrint(PrintWriter, ...) Message-ID: <46CD9B33.6020809@redhat.com> FYI, The conversion to those is largely finished; and the old toString methods have been removed. In using frysk, if you encounter a value like <> then we've a lurking toString() call. A test case to flush this out would really be appreciated. Andrew From scox@redhat.com Thu Aug 23 21:33:00 2007 From: scox@redhat.com (Stan Cox) Date: Thu, 23 Aug 2007 21:33:00 -0000 Subject: Value/Location Message-ID: <1187904534.968.63.camel@multics.rdu.redhat.com> The frysk.value constructor (Type type, String textFIXME) ->calls (new Location(type.getSize()) ->calls new ArrayByteBuffer(capacity) which will assume a big endian buffer One possibility is to have Value do: abb = new ArrayByteBuffer (..); abb.order(type.endian); Location(abb) From kris.van.hees@oracle.com Fri Aug 24 05:51:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Fri, 24 Aug 2007 05:51:00 -0000 Subject: Again the build is broken :( Message-ID: <20070824055011.GA19064@oracle.com> Again, we have a broken build with the following error: <> Running autoconf ... for libunwind Running aclocal ... for frysk-imports Running autoconf ... for frysk-imports Running automake ... for frysk-imports configure.ac: installing `./install-sh' configure.ac: installing `./missing' tests/Makefile.am: installing `./compile' tests/Makefile.am: installing `./depcomp' common/frysk-common.ac:222: installing `./config.guess' common/frysk-common.ac:222: installing `./config.sub' common/Makefile.rules:101: variable `GEN_GCJ_LDADD' is defined but no program or common/Makefile.rules:101: library has `GEN_GCJ' as canonic name (possible typo) Makefile.am:40: `common/Makefile.rules' included from here Problem in directory frysk-imports ../frysk_config/autogen.sh: line 57: ../frysk_config/configure: No such file or directory The cause seems to be the following commit: 2007-08-23 Andrew Cagney * Makefile.rules (fryski, gij.sh): Delete targets. I hope Mark or anyone else in a more convenient timezone may be able to commit a fix for this. Still recovering a bit from my travel yesterday, I'm more likely to cause additional problems than to solve this one right now. Finally, it seems like we're getting a lot more broken build cases lately than we've had in the past months. I am not sure what is causing this, because it seems like there have not really been any procedural changes that would cause this regression in quality. That leaves the question: what can we do about this? Assuming pre-commit testing is being done appropriately (i.e. using a clean slate - no left over configure scipts etc generated in a previous build), a problem like this can only be the result of a problem in how we perform the pre-commit testing. What can we do to improive upon it? Cheers, Kris From mark@klomp.org Fri Aug 24 08:16:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Fri, 24 Aug 2007 08:16:00 -0000 Subject: Again the build is broken :( In-Reply-To: <20070824055011.GA19064@oracle.com> References: <20070824055011.GA19064@oracle.com> Message-ID: <1187943385.3749.12.camel@dijkstra.wildebeest.org> Hi Kris, On Fri, 2007-08-24 at 01:50 -0400, Kris Van Hees wrote: > Again, we have a broken build with the following error: > > <> > Running autoconf ... for libunwind > Running aclocal ... for frysk-imports > Running autoconf ... for frysk-imports > Running automake ... for frysk-imports > configure.ac: installing `./install-sh' > configure.ac: installing `./missing' > tests/Makefile.am: installing `./compile' > tests/Makefile.am: installing `./depcomp' > common/frysk-common.ac:222: installing `./config.guess' > common/frysk-common.ac:222: installing `./config.sub' > common/Makefile.rules:101: variable `GEN_GCJ_LDADD' is defined but no program or > common/Makefile.rules:101: library has `GEN_GCJ' as canonic name (possible typo) > Makefile.am:40: `common/Makefile.rules' included from here > Problem in directory frysk-imports > ../frysk_config/autogen.sh: line 57: ../frysk_config/configure: No such file or directory Got more info on the build? Architecture, distro, gcc, automake/autoconf versions, etc? > I hope Mark or anyone else in a more convenient timezone may be able to commit > a fix for this. Still recovering a bit from my travel yesterday, I'm more > likely to cause additional problems than to solve this one right now. As it happens in this timezone everything works after a fresh checkout and fresh build (Fedora Core 6/x86_64, gcc 4.1.2-13, automake 1.9.6, autoconf 2.59 and Fedora 7/x86, gcc 4.1.2-12, automake 1.10, autoconf 2.61). I personally suspect the autotools or having to completely throw away your build dir (which is what I just do each morning). > Finally, it seems like we're getting a lot more broken build cases > lately than we've had in the past months. I am not sure what is > causing this, because it seems like there have not really been any > procedural changes that would cause this regression in quality. That > leaves the question: what can we do about this? Assuming pre-commit > testing is being done appropriately (i.e. using a clean slate - no > left over configure scipts etc generated in a previous build), a > problem like this can only be the result of a problem in how we > perform the pre-commit testing. What can we do to improive upon it? Personally I have found it helpful to make sure I have a separate patch that I can discuss and post to the list before committing. Often, just the fact that I need to generate the diff, apply it to a clean build (possibly on another machine) and just explain what the patch does helps find any silly small mistakes with it. Cheers, Mark From mark@klomp.org Fri Aug 24 11:12:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Fri, 24 Aug 2007 11:12:00 -0000 Subject: Again the build is broken :( In-Reply-To: <1187943385.3749.12.camel@dijkstra.wildebeest.org> References: <20070824055011.GA19064@oracle.com> <1187943385.3749.12.camel@dijkstra.wildebeest.org> Message-ID: <1187953952.24666.7.camel@dijkstra.wildebeest.org> Hi Kris, On Fri, 2007-08-24 at 10:16 +0200, Mark Wielaard wrote: > > I hope Mark or anyone else in a more convenient timezone may be able to commit > > a fix for this. Still recovering a bit from my travel yesterday, I'm more > > likely to cause additional problems than to solve this one right now. > > As it happens in this timezone everything works after a fresh checkout > and fresh build (Fedora Core 6/x86_64, gcc 4.1.2-13, automake 1.9.6, > autoconf 2.59 and Fedora 7/x86, gcc 4.1.2-12, automake 1.10, autoconf > 2.61). > > I personally suspect the autotools or having to completely throw away > your build dir (which is what I just do each morning). Doh. I lied (a little). Now that I do a completely fresh build (including cloning a fresh source repository) I did get the same failure. common/Makefile.rules:101: variable `GEN_GCJ_LDADD' is defined but no program or common/Makefile.rules:101: library has `GEN_GCJ' as canonic name (possible typo) Makefile.am:40: `common/Makefile.rules' included from here Problem in directory frysk-imports ../frysk/autogen.sh: line 57: ../frysk/configure: No such file or directory The reason I didn't see it before was that I wasn't doing a full clean build and there was still an old configure file left. Investigating. Cheers, Mark From mark@klomp.org Fri Aug 24 11:47:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Fri, 24 Aug 2007 11:47:00 -0000 Subject: Again the build is broken :( In-Reply-To: <1187953952.24666.7.camel@dijkstra.wildebeest.org> References: <20070824055011.GA19064@oracle.com> <1187943385.3749.12.camel@dijkstra.wildebeest.org> <1187953952.24666.7.camel@dijkstra.wildebeest.org> Message-ID: <1187956025.24666.15.camel@dijkstra.wildebeest.org> Hi, On Fri, 2007-08-24 at 13:12 +0200, Mark Wielaard wrote: > common/Makefile.rules:101: variable `GEN_GCJ_LDADD' is defined but no program or > common/Makefile.rules:101: library has `GEN_GCJ' as canonic name (possible typo) > Makefile.am:40: `common/Makefile.rules' included from here > Problem in directory frysk-imports > ../frysk/autogen.sh: line 57: ../frysk/configure: No such file or directory > > The reason I didn't see it before was that I wasn't doing a full clean > build and there was still an old configure file left. Investigating. OK, found it. automake thinks anything ending in _LDADD is "magic". So a simple change to use a non-magic-sounding variable fixes things: common/ChangeLog 2007-08-24 Mark Wielaard * Makefile.rules: Change GEN_GCJ_LDADD to GEN_GCJ_LDADD_LIST. * Makefile.gen.sh: Likewise. frysk-core/ChangeLog 2007-08-24 Mark Wielaard * Makefile.am: Change GEN_GCJ_LDADD to GEN_GCJ_LDADD_LIST. frysk-gtk/ChangeLog 2007-08-24 Mark Wielaard * Makefile.am: Change GEN_GCJ_LDADD to GEN_GCJ_LDADD_LIST. frysk-gui/ChangeLog 2007-08-24 Mark Wielaard * Makefile.am: Change GEN_GCJ_LDADD to GEN_GCJ_LDADD_LIST. frysk-imports/ChangeLog 2007-08-24 Mark Wielaard * Makefile.am: Change GEN_GCJ_LDADD to GEN_GCJ_LDADD_LIST. frysk-sys/ChangeLog 2007-08-24 Mark Wielaard * Makefile.am: Change GEN_GCJ_LDADD to GEN_GCJ_LDADD_LIST. Tested on FC6 with automake 1.9.6 and F7 with automake 1.10. I don't know why this wasn't a problem before the removal of fryski though. So some extra testing is appreciated. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: ldadd_list.patch Type: text/x-patch Size: 12880 bytes Desc: not available URL: From cagney@redhat.com Fri Aug 24 12:34:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 24 Aug 2007 12:34:00 -0000 Subject: Again the build is broken :( In-Reply-To: <1187943385.3749.12.camel@dijkstra.wildebeest.org> References: <20070824055011.GA19064@oracle.com> <1187943385.3749.12.camel@dijkstra.wildebeest.org> Message-ID: <46CED04A.9070003@redhat.com> > Got more info on the build? Architecture, distro, gcc, automake/autoconf > versions, etc? Seems its only triggered by newer autotools. Andrew From cagney@redhat.com Fri Aug 24 12:54:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 24 Aug 2007 12:54:00 -0000 Subject: Value/Location In-Reply-To: <1187904534.968.63.camel@multics.rdu.redhat.com> References: <1187904534.968.63.camel@multics.rdu.redhat.com> Message-ID: <46CED526.402@redhat.com> Yes, Every time I tried to get frysk.value.Format to use the type's byte-order I'd get test-suite failures caused by another case of this. The underling problem is that type code used to read/write byte-order dependent values wasn't explicitly specifying the type's required byte-order. Hopefully the last of these get flushed out with the next few commits. Andrew Stan Cox wrote: > The frysk.value constructor (Type type, String textFIXME) > ->calls (new Location(type.getSize()) > ->calls new ArrayByteBuffer(capacity) > which will assume a big endian buffer > > One possibility is to have Value do: > abb = new ArrayByteBuffer (..); > abb.order(type.endian); > Location(abb) > > > > From elena.zannoni@oracle.com Fri Aug 24 14:26:00 2007 From: elena.zannoni@oracle.com (Elena Zannoni) Date: Fri, 24 Aug 2007 14:26:00 -0000 Subject: Again the build is broken :( In-Reply-To: <46CED04A.9070003@redhat.com> References: <20070824055011.GA19064@oracle.com> <1187943385.3749.12.camel@dijkstra.wildebeest.org> <46CED04A.9070003@redhat.com> Message-ID: <46CEEA89.7030803@oracle.com> Andrew Cagney wrote: > >> Got more info on the build? Architecture, distro, gcc, automake/autoconf >> versions, etc? > > Seems its only triggered by newer autotools. > > Andrew > This leads to the question as to what are the standard development platforms for frysk. FC6 and FC7? Or is older stuff still used? Should there be a standard platform where pre-commit build and tests should be performed. From mark@klomp.org Fri Aug 24 14:39:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Fri, 24 Aug 2007 14:39:00 -0000 Subject: Again the build is broken :( In-Reply-To: <46CEEA89.7030803@oracle.com> References: <20070824055011.GA19064@oracle.com> <1187943385.3749.12.camel@dijkstra.wildebeest.org> <46CED04A.9070003@redhat.com> <46CEEA89.7030803@oracle.com> Message-ID: <1187966328.24666.20.camel@dijkstra.wildebeest.org> Hi Elena, On Fri, 2007-08-24 at 10:26 -0400, Elena Zannoni wrote: > This leads to the question as to what are the standard development > platforms for frysk. > FC6 and FC7? Or is older stuff still used? Should there be a standard > platform where > pre-commit build and tests should be performed. I am personally using Fedora Core 6 (x86_64) as main development platform and test everything (quickly) on Fedora 7 (x86) before committing. But I guess other people have other platforms available. I do appreciate the autobuilder Kris setup since that shows some more platforms. Maybe we can change it a little to better show which patch breaks what on which platform, but that would mean actually building each commit, which might be a little too much for the system. Cheers, Mark From pmuldoon@redhat.com Fri Aug 24 15:17:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 24 Aug 2007 15:17:00 -0000 Subject: Again the build is broken :( In-Reply-To: <1187966328.24666.20.camel@dijkstra.wildebeest.org> References: <20070824055011.GA19064@oracle.com> <1187943385.3749.12.camel@dijkstra.wildebeest.org> <46CED04A.9070003@redhat.com> <46CEEA89.7030803@oracle.com> <1187966328.24666.20.camel@dijkstra.wildebeest.org> Message-ID: <46CEF687.6020502@redhat.com> Mark Wielaard wrote: > Hi Elena, > > On Fri, 2007-08-24 at 10:26 -0400, Elena Zannoni wrote: > >> This leads to the question as to what are the standard development >> platforms for frysk. >> FC6 and FC7? Or is older stuff still used? Should there be a standard >> platform where >> pre-commit build and tests should be performed. >> > > I am personally using Fedora Core 6 (x86_64) as main development > platform and test everything (quickly) on Fedora 7 (x86) before > committing. But I guess other people have other platforms available. I > do appreciate the autobuilder Personally I think an auto-builder is here for precisely the purpose shown, in catching architecture-release build combinations breakages. I just do not have the time to test arch * distro. The numbers add up, and I normally test x86 and x86_64 on Fedora 7. There's no reason to spend expensive and scarce human-time checking these, when a build matrix can do it better, especially when the fixes are simple oversights. I'd rather have people contributing to features and fixing known bugs and, to that end, making Frysk better. And letting build matrices build on every platform/release known to us, and linting test-cases and build issues. Regards Phil From pmuldoon@redhat.com Fri Aug 24 15:30:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 24 Aug 2007 15:30:00 -0000 Subject: Mercurial and Frysk Message-ID: <46CEF99E.1000902@redhat.com> Mark's Mercurial repository experiment has been online for a couple of weeks now: http://gnu.wildebeest.org/hg/frysk/ http://gnu.wildebeest.org/trac/frysk/ Moving forward so we do not spend forever stuck in limbo, I'd like to continue to push the conversation. Have you tried it? What do you think of Mercurial as a whole? What do you think of Mercurial with Frysk? Personally I feel change is in the wind over many projects, with the kernel and Mozilla being two very well known names moving to a distributed control system. I know mark uses this locally, and I will be for the next week. It's a one way mirror, so commits will not show up in CVS. Regards Phil From elena.zannoni@oracle.com Fri Aug 24 16:14:00 2007 From: elena.zannoni@oracle.com (Elena Zannoni) Date: Fri, 24 Aug 2007 16:14:00 -0000 Subject: Again the build is broken :( In-Reply-To: <46CEF687.6020502@redhat.com> References: <20070824055011.GA19064@oracle.com> <1187943385.3749.12.camel@dijkstra.wildebeest.org> <46CED04A.9070003@redhat.com> <46CEEA89.7030803@oracle.com> <1187966328.24666.20.camel@dijkstra.wildebeest.org> <46CEF687.6020502@redhat.com> Message-ID: <46CF03A8.2030805@oracle.com> Phil Muldoon wrote: > Mark Wielaard wrote: >> Hi Elena, >> >> On Fri, 2007-08-24 at 10:26 -0400, Elena Zannoni wrote: >> >>> This leads to the question as to what are the standard development >>> platforms for frysk. >>> FC6 and FC7? Or is older stuff still used? Should there be a >>> standard platform where >>> pre-commit build and tests should be performed. >>> >> >> I am personally using Fedora Core 6 (x86_64) as main development >> platform and test everything (quickly) on Fedora 7 (x86) before >> committing. But I guess other people have other platforms available. I >> do appreciate the autobuilder > Personally I think an auto-builder is here for precisely the purpose > shown, in catching architecture-release build combinations breakages. > I just do not have the time to test arch * distro. The numbers add up, > and I normally test x86 and x86_64 on Fedora 7. There's no reason to > spend expensive and scarce human-time checking these, when a build > matrix can do it better, especially when the fixes are simple oversights. > I'd rather have people contributing to features and fixing known bugs > and, to that end, making Frysk better. And letting build matrices > build on every platform/release known to us, and linting test-cases > and build issues. > Sure, the two things you mention are not mutually exclusive. However there is a cost to identifying broken builds too, and it seems that Mark is drawing the short straw frequently, since he is usually the first to correct said oversights. It takes away some of his time from development. I haven't suggested that you or anybody checks every combination before checking stuff in. What I have suggested is that, like we used to do once upon a time, we stick with as few development platforms as we can get away with in order to minimize the oversights. So if the platforms supported are FC6 and F7, let's stick with those and make everybody's life easier. If somebody wants to add FC5 to the test grid, please do so and contribute the tests results so that they can be uploaded. Any takers? elena From kris.van.hees@oracle.com Fri Aug 24 16:44:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Fri, 24 Aug 2007 16:44:00 -0000 Subject: Again the build is broken :( In-Reply-To: <1187966328.24666.20.camel@dijkstra.wildebeest.org> References: <20070824055011.GA19064@oracle.com> <1187943385.3749.12.camel@dijkstra.wildebeest.org> <46CED04A.9070003@redhat.com> <46CEEA89.7030803@oracle.com> <1187966328.24666.20.camel@dijkstra.wildebeest.org> Message-ID: <20070824164222.GB19064@oracle.com> On Fri, Aug 24, 2007 at 04:38:48PM +0200, Mark Wielaard wrote: > I am personally using Fedora Core 6 (x86_64) as main development > platform and test everything (quickly) on Fedora 7 (x86) before > committing. But I guess other people have other platforms available. I > do appreciate the autobuilder Kris setup since that shows some more > platforms. Maybe we can change it a little to better show which patch > breaks what on which platform, but that would mean actually building > each commit, which might be a little too much for the system. Actually, we could get fairly close to a per-commit building if we could get the build process that frysk uses a bit more streamlined. That might involve quite a bit of work though, and someone will need to be given the cycles to do it. Even without a per-commit build it is possible to report on changes that occured between two builds (and in fact, the web site currently provides all anyone needs to do that already - the .rev files contain both a date/time stamp of the checkout/update and a list of the exact CVS reivision IDs, so comparing two you get an exact list of what files changed and what the source and target revisions are per file). Fortunately, it has almost always been extremely obvious what broke the build, even wth just daily builds. So, it may not be that big of a problem to solve right now. The ultimate problem remains though... no one has made any contribution to the autobuild system, and the one promise to contribute running builds never happened. There are limitations to how much can be done in reasonable time without builds being contributed. Cheers, Kris From cagney@redhat.com Fri Aug 24 21:00:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 24 Aug 2007 21:00:00 -0000 Subject: Again the build is broken :( In-Reply-To: <46CF03A8.2030805@oracle.com> References: <20070824055011.GA19064@oracle.com> <1187943385.3749.12.camel@dijkstra.wildebeest.org> <46CED04A.9070003@redhat.com> <46CEEA89.7030803@oracle.com> <1187966328.24666.20.camel@dijkstra.wildebeest.org> <46CEF687.6020502@redhat.com> <46CF03A8.2030805@oracle.com> Message-ID: <46CF46E8.6020706@redhat.com> Elena Zannoni wrote: > Sure, the two things you mention are not mutually exclusive. > However there is a cost to identifying broken builds too, and it seems > that Mark is drawing the > short straw frequently, since he is usually the first to correct said > oversights. It takes away some > of his time from development. Quite frequently, during the American day, we encounter and quick fix similar issues (just today there was another "oops"), and we're successfully and co-operatively managing these hiccups through our IRC chatter and/or through bug reports and commits. However, we do need to be careful. Both Pearly and Mark pick up what I'll call the night shift (from my tz pov) and so occasionally might be first to encounter a problem also encountered by this build system. There I think the most important thing is for us to be careful that we don't message an expectation that Pearly and/or Mark are some how expected to down-tools and focus all energies on getting it fixed. As with us during the day, back-date the check-out for a few hours 'til things are resolved; for mark using mecurial, this is trivial. Can I suggest: - Moving the build farm's time to run just before US dawn so results are better timed for us waking up; or better ... - setting up a test system that makes available results from individual commits and not fuzzy dates - accept that an occasional build failure in the build farm does not require an immediate post about the sky falling; I for instance would only be concerned if the build failed consistently and for an identical reason across two work days; and then my first response is still going to be to fix it. Andrew > I haven't suggested that you or anybody checks every combination > before checking stuff in. What I have suggested is that, like we used > to do once upon a time, we > stick with as few development platforms as we can get away with in > order to minimize the > oversights. So if the platforms supported are FC6 and F7, let's stick > with those and make > everybody's life easier. If somebody wants to add FC5 to the test > grid, please do so and contribute > the tests results so that they can be uploaded. Any takers? From kris.van.hees@oracle.com Sun Aug 26 21:21:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Sun, 26 Aug 2007 21:21:00 -0000 Subject: Again the build is broken :( Message-ID: <20070826211939.GB22263@oracle.com> Well, 1) If the time at which the automated builds run is significant in any way, we have a problem with our development procedures, because the quality of code (and the commits) should obviously not be time dependent. Also note that the builds are currently being executed at the following time slots: coldstone 3:34 am EST ca-tools2 4:45 am EST Given that the entire build-and-test cycle currently takes about 1 hour, that puts the completion of the latter right before EST dawn. And you can of course schedule your own builds using the automated build and test system at any time you want. In fact, I'd highly recommend doing that, because it helps out everyone by increasing the overall build-and-test coverage. 2) I think you would definitely make a great contribution to the testing of frysk if you could create a per-commit test system. I also believe it would make a nice complement to the current build-and-test system. I look forward to hearing (and seeing) more about this. I'd like to point out though that there is nothing fuzzy about the point in time where a specific build was done by the automated build-and-test system. It is in fact possible (quite easily) to reconstruct the exact source tree that was used for the build (using CVS, so there is full access to commit log messages, etc...) 3) I don't think anyone has been reporting disaster in the event of build failures due to commits breaking the build, but I do believe that it is worth mentioning when it happens. At a minimum, it raises the point that we are not as successful as we could be in making sure that commits are not breaking the builds. Also, almost every single build failure *has* been discussed on IRC as soon as it was found (and resolution usually followed fairly shortly thereafter). In this particular case, there was no IRC discussion (or at least, not initiated by me) simply because I was unable to connect to IRC at that given time. Rather than not mentioning anything, sending mail to the list seemed quite reasonable under those circumstances. Cheers, Kris > Elena Zannoni wrote: > >> Sure, the two things you mention are not mutually exclusive. >> However there is a cost to identifying broken builds too, and it seems >> that Mark is drawing the >> short straw frequently, since he is usually the first to correct said >> oversights. It takes away some >> of his time from development. >> > Quite frequently, during the American day, we encounter and quick fix > similar issues (just today there was another "oops"), and we're > successfully and co-operatively managing these hiccups through our IRC > chatter and/or through bug reports and commits. > > However, we do need to be careful. Both Pearly and Mark pick up what I'll > call the night shift (from my tz pov) and so occasionally might be first > to encounter a problem also encountered by this build system. There I > think the most important thing is for us to be careful that we don't > message an expectation that Pearly and/or Mark are some how expected to > down-tools and focus all energies on getting it fixed. As with us during > the day, back-date the check-out for a few hours 'til things are resolved; > for mark using mecurial, this is trivial. > > Can I suggest: > > - Moving the build farm's time to run just before US dawn so results are > better timed for us waking up; or better ... > > - setting up a test system that makes available results from individual > commits and not fuzzy dates > > - accept that an occasional build failure in the build farm does not > require an immediate post about the sky falling; I for instance would only > be concerned if the build failed consistently and for an identical reason > across two work days; and then my first response is still going to be to > fix it. > > Andrew > > > >> I haven't suggested that you or anybody checks every combination >> before checking stuff in. What I have suggested is that, like we used to >> do once upon a time, we >> stick with as few development platforms as we can get away with in order >> to minimize the >> oversights. So if the platforms supported are FC6 and F7, let's stick >> with those and make >> everybody's life easier. If somebody wants to add FC5 to the test grid, >> please do so and contribute >> the tests results so that they can be uploaded. Any takers? From cagney@redhat.com Mon Aug 27 13:37:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 27 Aug 2007 13:37:00 -0000 Subject: [Fwd: frysk-core/frysk/hpd AllPTSet.java ChangeLog V ...] Message-ID: <46D2D3B6.9030504@redhat.com> Tim, are we testing this? I see "fix" but I don't see testing code supporting the changes. Andrew -------------- next part -------------- An embedded message was scrubbed... From: moore@sourceware.org Subject: frysk-core/frysk/hpd AllPTSet.java ChangeLog V ... Date: 27 Aug 2007 10:49:46 -0000 Size: 2596 URL: From cagney@redhat.com Mon Aug 27 15:39:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 27 Aug 2007 15:39:00 -0000 Subject: -format options Message-ID: <46D2F057.7050901@redhat.com> Hi, some questions, and ideas. What should the -format qualifier do when applied to floating point? For instance: (fhpd) print 1.0 -format x 0x1 i.e., convert the cooked value to decimal and then print in hex; or: (fhpd) print 1.0 -format x 0x3ff0000000000000 i.e., print the raw value in hex. I think the answer depends on the next question. What possible format options are there and how should they interact? Here's a possible list: bi[t]s, [o]ctal, [d]ecimal, he[x]adecimal, [f]loat, [v]alue (i.e., default) [r]aw, [c]ooked [b]ig-endian, [l]ittle-endian, [n]ative (for default) [s]igned, [u]nsigned, [i]nteger (for default???) reset: - are there others? I've tried to make each set largely orthogonal; does this work? Would other combinations be better? For signed/unsigned is there a better "default" to integer. Should [o][x][t] just imply unsigned? How should these options be specified; Either: -format rx or -format x -data r -order b for dumping each field in big-endian raw hex. I prefer the more terse former. From cmoller@redhat.com Mon Aug 27 15:58:00 2007 From: cmoller@redhat.com (Chris Moller) Date: Mon, 27 Aug 2007 15:58:00 -0000 Subject: -format options In-Reply-To: <46D2F057.7050901@redhat.com> References: <46D2F057.7050901@redhat.com> Message-ID: <46D2F498.9000407@redhat.com> Any reason you couldn't just pass a kind of printf format string to -format. E.g., print 1.0 "%g 0x%08x" would print the value first as a double--1.0--and then again in hex. (Unlike printf, each % substitution would refer to the same value.) cm Andrew Cagney wrote: > Hi, > > some questions, and ideas. > > What should the -format qualifier do when applied to floating point? > For instance: > (fhpd) print 1.0 -format x > 0x1 > i.e., convert the cooked value to decimal and then print in hex; or: > (fhpd) print 1.0 -format x > 0x3ff0000000000000 > i.e., print the raw value in hex. I think the answer depends on the > next question. > > What possible format options are there and how should they interact? > Here's a possible list: > bi[t]s, [o]ctal, [d]ecimal, he[x]adecimal, [f]loat, [v]alue (i.e., > default) > [r]aw, [c]ooked > [b]ig-endian, [l]ittle-endian, [n]ative (for default) > [s]igned, [u]nsigned, [i]nteger (for default???) > reset: - > are there others? I've tried to make each set largely orthogonal; > does this work? Would other combinations be better? For > signed/unsigned is there a better "default" to integer. Should > [o][x][t] just imply unsigned? > > How should these options be specified; Either: > -format rx > or > -format x -data r -order b > for dumping each field in big-endian raw hex. I prefer the more terse > former. > -- Chris Moller Java: the blunt scissors of programming languages. -- Dave Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From cagney@redhat.com Mon Aug 27 16:16:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 27 Aug 2007 16:16:00 -0000 Subject: -format options In-Reply-To: <46D2F498.9000407@redhat.com> References: <46D2F057.7050901@redhat.com> <46D2F498.9000407@redhat.com> Message-ID: <46D2F8EA.4090700@redhat.com> Chris Moller wrote: > Any reason you couldn't just pass a kind of printf format string to > -format. E.g., > > print 1.0 "%g 0x%08x" > > would print the value first as a double--1.0--and then again in hex. > (Unlike printf, each % substitution would refer to the same value.) > interesting idea; I'm not sure how well it will interact with more complex values for instance: (fhpd) print a_struct { i = 1, f = 1.0 } and: (fhpd) print a_struct -format rx { i - 0x1, f = 0x3f800000 } however a separate << printf option list >> command might make for an interesting extension; for instance: (fhpd) printf "%x\n", a_struct 0x1, 0x3f800000 i.e., apply a printf format to all elements of the value. Andrew PS: The fhpd outlines the command << print -format >> > cm > > > Andrew Cagney wrote: > >> Hi, >> >> some questions, and ideas. >> >> What should the -format qualifier do when applied to floating point? >> For instance: >> (fhpd) print 1.0 -format x >> 0x1 >> i.e., convert the cooked value to decimal and then print in hex; or: >> (fhpd) print 1.0 -format x >> 0x3ff0000000000000 >> i.e., print the raw value in hex. I think the answer depends on the >> next question. >> >> What possible format options are there and how should they interact? >> Here's a possible list: >> bi[t]s, [o]ctal, [d]ecimal, he[x]adecimal, [f]loat, [v]alue (i.e., >> default) >> [r]aw, [c]ooked >> [b]ig-endian, [l]ittle-endian, [n]ative (for default) >> [s]igned, [u]nsigned, [i]nteger (for default???) >> reset: - >> are there others? I've tried to make each set largely orthogonal; >> does this work? Would other combinations be better? For >> signed/unsigned is there a better "default" to integer. Should >> [o][x][t] just imply unsigned? >> >> How should these options be specified; Either: >> -format rx >> or >> -format x -data r -order b >> for dumping each field in big-endian raw hex. I prefer the more terse >> former. >> >> > > From swagiaal@redhat.com Mon Aug 27 18:23:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Mon, 27 Aug 2007 18:23:00 -0000 Subject: elfutils import In-Reply-To: <46CCAE6A.3000904@redhat.com> References: <46CCAE6A.3000904@redhat.com> Message-ID: <46D31690.70801@redhat.com> > To get a merged version of the tree I do this: > > cvs -d:ext:swagiaal@sources.redhat.com:/cvs/frysk checkout -j > elfutils_0_127 -j elfutils_0_129 frysk > > I then resolve all the conflicts by blindly favoring upstream. > I have committed the merge to this branch: sami-elfutils_129-merge-20070827-branch check it out like this: cvs -d:ext:swagiaal@sources.redhat.com:/cvs/frysk checkout -r sami-elfutils_129-merge-20070827-branch frysk attached are the test results from frysk-core -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test_results URL: From swagiaal@redhat.com Mon Aug 27 19:29:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Mon, 27 Aug 2007 19:29:00 -0000 Subject: elfutils import In-Reply-To: <20070822215158.AFB804D0418@magilla.localdomain> References: <20070822215158.AFB804D0418@magilla.localdomain> Message-ID: <46D32573.6070904@redhat.com> > Please show me all the differences in that tree from the upstream elfutils. > You should not be carrying any. > Sorry for the late reply... I was away for a couple of days. I dont think we plan to carry any of these differences. But I attached the patch anways: The following files contain conflicts: configure.ac libdwfl/dwfl_module.c libdwfl/dwfl_module_addrsym.c src/ldlex.c tests/Makefile.am ChangeLog backends/ChangeLog libdwfl/ChangeLog tests/ChangeLog [ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cvsdiff URL: From roland@redhat.com Mon Aug 27 20:21:00 2007 From: roland@redhat.com (Roland McGrath) Date: Mon, 27 Aug 2007 20:21:00 -0000 Subject: elfutils import In-Reply-To: Sami Wagiaalla's message of Monday, 27 August 2007 15:26:43 -0400 <46D32573.6070904@redhat.com> Message-ID: <20070827202033.D62924D05BE@magilla.localdomain> That diff was really not useful. Please post the diff between what you have in the frysk tree and the corresponding vanilla elfutils source. From pmuldoon@redhat.com Tue Aug 28 00:19:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 28 Aug 2007 00:19:00 -0000 Subject: Again the build is broken :( In-Reply-To: <46CF03A8.2030805@oracle.com> References: <20070824055011.GA19064@oracle.com> <1187943385.3749.12.camel@dijkstra.wildebeest.org> <46CED04A.9070003@redhat.com> <46CEEA89.7030803@oracle.com> <1187966328.24666.20.camel@dijkstra.wildebeest.org> <46CEF687.6020502@redhat.com> <46CF03A8.2030805@oracle.com> Message-ID: <46D369E5.6080805@redhat.com> Elena Zannoni wrote: >> > > Sure, the two things you mention are not mutually exclusive. > However there is a cost to identifying broken builds too, and it seems > that Mark is drawing the > short straw frequently, since he is usually the first to correct said > oversights. It takes away some > of his time from development. I'll segway into distributed version control here, my favorite pet topic ;) It's great for isolating people from other peoples commits, and the ability to locally remove (or re-pull) whatever patch-sets you like. This a good thing, if a patch is bothering you then remove that change-set, then pull it later when it is mixed. OTOH I think we all try to keep a stable CVS HEAD, but sometimes things just slip. Anyway, old ground there but ... > What I have suggested is that, like we used to do once upon a time, we > stick with as few development platforms as we can get away with in > order to minimize the > oversights. So if the platforms supported are FC6 and F7, let's stick > with those and make > everybody's life easier. If somebody wants to add FC5 to the test > grid, please do so and contribute > the tests results so that they can be uploaded. Any takers? I don't think the platforms have changed much since the time you talk about. But then again, there are other concerns now and in the future for other growth platforms. We have a Debian package now that Thomas works on. Mike is/was working on a Gentoo version. Fedora, RHEL and other distros. The math gets scary when you take platforms * architectures. Add into that the changing dynamics of the kernel across those platforms, and the only sane way to keep track of these is a build host. Ideally, in a hardware rich world I'd like to submit a job to a build farm so it could lint all this automatically. Especially when I work on CNI code. I don't see the build farm failing as a "failure" but rather "doing its job". Regards Phil From mark@klomp.org Tue Aug 28 11:01:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Tue, 28 Aug 2007 11:01:00 -0000 Subject: DummyDisassembler for fstep Message-ID: <1188298851.3817.7.camel@dijkstra.wildebeest.org> Hi, In the last test reports I saw that FStep.testFirstStep was disabled because we don't have a disassembler anymore. This made me a little nervous since the test isn't actually testing the disassembler at all and the test is a good indicator of subtle observer issues with stepping and breakpoints. So I added a quick and dirty DummyDisassembler to fstep that is used when no full blown Disassembler is available. 2007-08-28 Mark Wielaard * fstep.java (DummyDisassembler): New static helper class. (updateAttached): Create DummyDisassembler when needed. (updateHit): Add new observers first before removing Code observer. * TestFStep.java: Always supported. With this the test passes again and now fstep even gives some useful output even without the full disassembler. Maybe someone wants to make this more generic for other consumers of the disassembler? Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: fstep-dummy-dis.patch Type: text/x-patch Size: 2996 bytes Desc: not available URL: From cagney@redhat.com Tue Aug 28 13:25:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 28 Aug 2007 13:25:00 -0000 Subject: elfutils import In-Reply-To: <46D32573.6070904@redhat.com> References: <20070822215158.AFB804D0418@magilla.localdomain> <46D32573.6070904@redhat.com> Message-ID: <46D42272.8020607@redhat.com> Sami Wagiaalla wrote: > >> Please show me all the differences in that tree from the upstream >> elfutils. >> You should not be carrying any. >> > Sorry for the late reply... I was away for a couple of days. > > I dont think we plan to carry any of these differences. > > But I attached the patch anways: > > The following files contain conflicts: > > configure.ac > libdwfl/dwfl_module.c > libdwfl/dwfl_module_addrsym.c > src/ldlex.c > tests/Makefile.am > > ChangeLog > backends/ChangeLog > libdwfl/ChangeLog > tests/ChangeLog Sami, Hmm, this diff looks too big. Perhaps try diffing our head with the last import so you can see what changes there were; like you note we're constantly trying to eliminate them. With regard to the test failures; they're in symtab lookup. May be double check that our temporary fixes were flushed during the import. Andrew From cagney@redhat.com Tue Aug 28 20:44:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 28 Aug 2007 20:44:00 -0000 Subject: meeting 2007-08-29 9:30 US east Message-ID: <46D4892C.7070309@redhat.com> Topics: -> process/thread focus [timoore] -> "print -format" again [cagney] From swagiaal@redhat.com Tue Aug 28 21:06:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Tue, 28 Aug 2007 21:06:00 -0000 Subject: Mercurial and Frysk In-Reply-To: <46CEF99E.1000902@redhat.com> References: <46CEF99E.1000902@redhat.com> Message-ID: <46D48E50.8050502@redhat.com> > Moving forward so we do not spend forever stuck in limbo, I'd like to > continue to push the conversation. Have you tried it? What do you > think of Mercurial as a whole? What do you think of Mercurial with Frysk? If there are no objections lets start the move the Mercurial From timoore@redhat.com Tue Aug 28 22:38:00 2007 From: timoore@redhat.com (Tim Moore) Date: Tue, 28 Aug 2007 22:38:00 -0000 Subject: Mercurial and Frysk In-Reply-To: <46D48E50.8050502@redhat.com> References: <46CEF99E.1000902@redhat.com> <46D48E50.8050502@redhat.com> Message-ID: <46D4A3DB.3050906@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sami Wagiaalla wrote: > >> Moving forward so we do not spend forever stuck in limbo, I'd like to >> continue to push the conversation. Have you tried it? What do you >> think of Mercurial as a whole? What do you think of Mercurial with Frysk? > If there are no objections lets start the move the Mercurial Is anyone prepared to contrast its use with git yet? I admit I'm not, but I've been pretty happy with my git mirror of frysk. Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG1KPbeDhWHdXrDRURAiWZAJ9DwUqfnLvad5y71UaGT8OskvjskgCdG7Xj SpXnsPt8k70sq3vPhoAHJdk= =sWBa -----END PGP SIGNATURE----- From elena.zannoni@oracle.com Wed Aug 29 14:54:00 2007 From: elena.zannoni@oracle.com (Elena Zannoni) Date: Wed, 29 Aug 2007 14:54:00 -0000 Subject: Minutes meeting 2007-08-29 Message-ID: <46D58842.9060805@oracle.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: frysk-20070829 URL: From cagney@redhat.com Wed Aug 29 14:58:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 29 Aug 2007 14:58:00 -0000 Subject: meeting 2007-08-29 9:30 US east In-Reply-To: <46D4892C.7070309@redhat.com> References: <46D4892C.7070309@redhat.com> Message-ID: <46D5897B.3090304@redhat.com> Andrew Cagney wrote: > Topics: > -> "print -format" again [cagney] > Discussion around what to do with: (hpd) print 1.0 -format x vis: 0x3f800000 -> dump the raw data 1 -> cast to int and print that 0x1.0 -> print as floating-point but in base 16; see fprintf(3)'s %a consensus was the last option, which also allowed things like: (fhpd) print 1.5 -format t 1.1 i.e., print the floating-point value as binary (but still interpreted as floating-point). ---- bugs found: (hpd) regs -> using toString() and not toPrint() http://sourceware.org/bugzilla/show_bug.cgi?id=4975 (hpd) help regs -> doesn't mention what register groups are available http://sourceware.org/bugzilla/show_bug.cgi?id=4974 (hpd) print $eax -format f -> gets a parser error http://sourceware.org/bugzilla/show_bug.cgi?id=4973 (fhpd) print -format bi[t] not supported http://sourceware.org/bugzilla/show_bug.cgi?id=4976 From mark@klomp.org Wed Aug 29 14:59:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 29 Aug 2007 14:59:00 -0000 Subject: Minutes meeting 2007-08-29 In-Reply-To: <46D58842.9060805@oracle.com> References: <46D58842.9060805@oracle.com> Message-ID: <1188399545.3823.0.camel@dijkstra.wildebeest.org> On Wed, 2007-08-29 at 10:52 -0400, Elena Zannoni wrote: > Frysk meeting 2007-08-29 > ========================== > > Tim, Andrew, Mark, Teresa, Elena, Phil, Sami. Haven't heard anybody > else speak, please add yourself if you were in attendance. > > [Mark to post the whole CLI session] There you go (attached). Cheers, Mark -------------- next part -------------- [mark@hermans frysk]$ bindir/fhpd (fhpd) run pkglibdir/funit-fib-clone 3 Attached to process 6347 (fhpd) break fib breakpoint 0 (fhpd) go (fhpd) Breakpoint 0 fib where #0 0x08048608 in fib(void * arg = 0x400000000003) /home/mark/src/frysk-obj/frysk-core/../../frysk/frysk-core/frysk/pkglibdir/funit-fib-clone.c#52 #1 0x0804876e in main(int argc = 8367484,byte * * argv = 0x6c0ce6,byte * * envp = 0x714b4000000000) /home/mark/src/frysk-obj/frysk-core/../../frysk/frysk-core/frysk/pkglibdir/funit-fib-clone.c#109 #2 0x006c0f70 in __libc_start_main () from /lib/libc-2.6.so #3 0x08048541 in _start () from /home/mark/src/frysk-obj/frysk-core/frysk/pkglibdir/funit-fib-clone (fhpd) go (fhpd) Breakpoint 0 fib Breakpoint 0 fib Breakpoint 0 fib Breakpoint 0 fib Breakpoint 0 fib where [0.0] [0.1] #0 0x08048608 in fib(void * arg = 0xb7f9048000000002) /home/mark/src/frysk-obj/frysk-core/../../frysk/frysk-core/frysk/pkglibdir/funit-fib-clone.c#52 #1 0x0084d44b in start_thread () from /lib/libpthread-2.6.so #2 0x0077b80e in clone () from /lib/libc-2.6.so [0.2] #0 0x08048608 in fib(void * arg = 0xb7f8c48000000001) /home/mark/src/frysk-obj/frysk-core/../../frysk/frysk-core/frysk/pkglibdir/funit-fib-clone.c#52 #1 0x0084d44b in start_thread () from /lib/libpthread-2.6.so #2 0x0077b80e in clone () from /lib/libc-2.6.so (fhpd) [0.1] where #0 0x08048608 in fib(void * arg = 0xb7f9048000000002) /home/mark/src/frysk-obj/frysk-core/../../frysk/frysk-core/frysk/pkglibdir/funit-fib-clone.c#52 #1 0x0084d44b in start_thread () from /lib/libpthread-2.6.so #2 0x0077b80e in clone () from /lib/libc-2.6.so Creating new HPD notation set. (fhpd) [stopped] where [0.1] #0 0x08048608 in fib(void * arg = 0xb7f9048000000002) /home/mark/src/frysk-obj/frysk-core/../../frysk/frysk-core/frysk/pkglibdir/funit-fib-clone.c#52 #1 0x0084d44b in start_thread () from /lib/libpthread-2.6.so #2 0x0077b80e in clone () from /lib/libc-2.6.so [0.2] #0 0x08048608 in fib(void * arg = 0xb7f8c48000000001) /home/mark/src/frysk-obj/frysk-core/../../frysk/frysk-core/frysk/pkglibdir/funit-fib-clone.c#52 #1 0x0084d44b in start_thread () from /lib/libpthread-2.6.so #2 0x0077b80e in clone () from /lib/libc-2.6.so Creating new stopped state set. (fhpd) [0.2] print arg [0.2] 0xb7f8c48000000001 Creating new HPD notation set. (fhpd) viewset Target set pid id [0.0] 6347 6347 [0.1] 6347 6352 [0.2] 6347 6353 (fhpd) [0.0] halt Creating new HPD notation set. (fhpd) where [0.0] #0 0x00110402 in __kernel_vsyscall () from [vdso] #1 0x0084e535 in pthread_join () from /lib/libpthread-2.6.so #2 0x080486a7 in fib(void * arg = 0x400000000003) /home/mark/src/frysk-obj/frysk-core/../../frysk/frysk-core/frysk/pkglibdir/funit-fib-clone.c#84 #3 0x0804876e in main(int argc = Symbol "argc" has an unknown type.,byte * * argv = Symbol "argv" has an unknown type.,byte * * envp = Symbol "envp" has an unknown type.) /home/mark/src/frysk-obj/frysk-core/../../frysk/frysk-core/frysk/pkglibdir/funit-fib-clone.c#109 #4 0x006c0f70 in __libc_start_main () from /lib/libc-2.6.so #5 0x08048541 in _start () from /home/mark/src/frysk-obj/frysk-core/frysk/pkglibdir/funit-fib-clone [0.1] #0 0x08048608 in fib(void * arg = 0xb7f9048000000002) /home/mark/src/frysk-obj/frysk-core/../../frysk/frysk-core/frysk/pkglibdir/funit-fib-clone.c#52 #1 0x0084d44b in start_thread () from /lib/libpthread-2.6.so #2 0x0077b80e in clone () from /lib/libc-2.6.so [0.2] #0 0x08048608 in fib(void * arg = 0xb7f8c48000000001) /home/mark/src/frysk-obj/frysk-core/../../frysk/frysk-core/frysk/pkglibdir/funit-fib-clone.c#52 #1 0x0084d44b in start_thread () from /lib/libpthread-2.6.so #2 0x0077b80e in clone () from /lib/libc-2.6.so (fhpd) [0.0] go Creating new HPD notation set. (fhpd) where [0.0] [0.1] #0 0x08048608 in fib(void * arg = 0xb7f9048000000002) /home/mark/src/frysk-obj/frysk-core/../../frysk/frysk-core/frysk/pkglibdir/funit-fib-clone.c#52 #1 0x0084d44b in start_thread () from /lib/libpthread-2.6.so #2 0x0077b80e in clone () from /lib/libc-2.6.so [0.2] #0 0x08048608 in fib(void * arg = 0xb7f8c48000000001) /home/mark/src/frysk-obj/frysk-core/../../frysk/frysk-core/frysk/pkglibdir/funit-fib-clone.c#52 #1 0x0084d44b in start_thread () from /lib/libpthread-2.6.so #2 0x0077b80e in clone () from /lib/libc-2.6.so (fhpd) [0.0-1] go Error: Erroneous p/t set notation, ',' expected (fhpd) [0.0:1] go Creating new HPD notation set. (fhpd) where [0.0] [0.1] #0 0x08048608 in fib(void * arg = 0xb7f9048000000002) /home/mark/src/frysk-obj/frysk-core/../../frysk/frysk-core/frysk/pkglibdir/funit-fib-clone.c#52 #1 0x0084d44b in start_thread () from /lib/libpthread-2.6.so #2 0x0077b80e in clone () from /lib/libc-2.6.so [0.2] #0 0x08048608 in fib(void * arg = 0xb7f8c48000000001) /home/mark/src/frysk-obj/frysk-core/../../frysk/frysk-core/frysk/pkglibdir/funit-fib-clone.c#52 #1 0x0084d44b in start_thread () from /lib/libpthread-2.6.so #2 0x0077b80e in clone () from /lib/libc-2.6.so (fhpd) go (fhpd) Exception in thread "Thread-1" java.lang.IllegalStateException: Already stepping at frysk.proc.Breakpoint.prepareStep(fhpd) at frysk.proc.live.LinuxTaskState$Running.sendContinue(fhpd) at frysk.proc.live.LinuxTaskState$BlockedSignal.handleUnblock(fhpd) at frysk.proc.live.LinuxTaskState$BlockedSignal.handleDeleteObservation(fhpd) at frysk.proc.Task.handleDeleteObservation(fhpd) at frysk.proc.TaskObservation.handleDelete(fhpd) at frysk.proc.live.LinuxProcState$3.handleDeleteObservation(fhpd) at frysk.proc.Proc$15.execute(fhpd) at frysk.event.EventLoop.runEventLoop(fhpd) at frysk.event.EventLoop.run(fhpd) fib (3) = 2 [mark@hermans frysk]$ !! bindir/fhpd (fhpd) run pkglibdir/funit-fib-clone 4 Attached to process 6371 (fhpd) break fib breakpoint 0 (fhpd) run Usage: run executable arguments* (fhpd) gog Error: Unrecognized command: gog. (fhpd) go (fhpd) Breakpoint 0 fib go (fhpd) Breakpoint 0 fib Breakpoint 0 fib Breakpoint 0 fib Breakpoint 0 fib Breakpoint 0 fib viewsets Error: Unrecognized command: viewsets. (fhpd) viewset Target set pid id [0.0] 6371 6371 [0.1] 6371 6373 [0.2] 6371 6374 (fhpd) focus [0.2] Creating new HPD notation set. (fhpd) where #0 0x08048608 in fib(void * arg = 0xb7f7248000000002) /home/mark/src/frysk-obj/frysk-core/../../frysk/frysk-core/frysk/pkglibdir/funit-fib-clone.c#52 #1 0x0084d44b in start_thread () from /lib/libpthread-2.6.so #2 0x0077b80e in clone () from /lib/libc-2.6.so (fhpd) go (fhpd) Breakpoint 0 fib Breakpoint 0 fib Breakpoint 0 fib Breakpoint 0 fib Breakpoint 0 fib Breakpoint 0 fib Breakpoint 0 fib Breakpoint 0 fib Breakpoint 0 fib viewset Target set pid id [0.2] 6371 6374 (fhpd) (fhpd) (fhpd) (fhpd) quit Quitting... From cagney@redhat.com Wed Aug 29 17:24:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 29 Aug 2007 17:24:00 -0000 Subject: assertEquals(BigInteger) and assertEquals(byte[]) Message-ID: <46D5ABF2.6020201@redhat.com> Just FYI, In addition to: assertEquals(String,byte[],byte[]) for checking that the contents of two byte buffers are identical, I'm now adding: assertEquals(String,long,BigInteger) assertEquals(String,BigInteger,BigInteger) for checking big-integer values. Andrew From ajocksch@redhat.com Wed Aug 29 18:40:00 2007 From: ajocksch@redhat.com (Adam Jocksch) Date: Wed, 29 Aug 2007 18:40:00 -0000 Subject: Trouble with frysk.expunit.Expect and fhpd Message-ID: <46D5BD8F.8070003@redhat.com> I've been trying to re-tool frysk.hpd.TestDisplayCommand to use funit-rt-varchange instead of hpd-c (bug #4951). However, the expect script fails when fhpd doesn't behave as expected when adding a breakpoint. I've attached the revised version of TestDisplayCommand.java as well as the log created by ./TestRunner -log frysk=FINE frysk.hpd.TestDisplayCommand. Running 'frysk/bindir/fhpd frysk/pkglibdir/funit-rt-varchange' from the frysk-core directory produces the expected results; it's only under Expect that fhpd is functioning strangely. I've also had fhpd hang when creating a display under expect, but I'm currently unable to reproduce that problem. Adam -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: frysk_core_event.log.28 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TestDisplayCommand.java Type: text/x-java Size: 3841 bytes Desc: not available URL: From cagney@redhat.com Wed Aug 29 19:01:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 29 Aug 2007 19:01:00 -0000 Subject: Trouble with frysk.expunit.Expect and fhpd In-Reply-To: <46D5BD8F.8070003@redhat.com> References: <46D5BD8F.8070003@redhat.com> Message-ID: <46D5C28C.20403@redhat.com> Adam Jocksch wrote: > I've been trying to re-tool frysk.hpd.TestDisplayCommand to use > funit-rt-varchange instead of hpd-c (bug #4951). However, the expect > script fails when fhpd doesn't behave as expected when adding a > breakpoint. I've attached the revised version of > TestDisplayCommand.java as well as the log created by ./TestRunner > -log frysk=FINE frysk.hpd.TestDisplayCommand. Running > 'frysk/bindir/fhpd frysk/pkglibdir/funit-rt-varchange' from the > frysk-core directory produces the expected results; it's only under > Expect that fhpd is functioning strangely. > see: http://sourceware.org/bugzilla/show_bug.cgi?id=4914 and 4919 ; missting synchronization in fhpd can lead to expunit can feeding it commands to fast. Try adding a sleep(5) after the run, but before the breakpoint is set; something like: e.send("run " + Config.getPkgLibFile("funit-stepping-asm") + "\n"); e.expect(5, "Attached.*\n" + prompt); // Remove this - #4919 and #4914. try { Thread.sleep(2000); } catch (Exception e) {} e.send("break #" + source + "#" + startLine + "\n"); e.expect("breakpoint.*\n" + prompt); if this lets it work, keep the sleep and mark the test as unresolved(4914). We can then still run it with --unresolved. > I've also had fhpd hang when creating a display under expect, but I'm > currently unable to reproduce that problem. > > Adam > ------------------------------------------------------------------------ > > testHpdDisplayCommands(frysk.hpd.TestDisplayCommand) ---- startTest ---- > frysk.expunit.Expect@219d38 new /dev/pts/3 pid 7551 args [/home/ajocksch/build/frysk/frysk-core/frysk/bindir/fhpd, /home/ajocksch/build/frysk/frysk-core/frysk/pkglibdir/funit-rt-varchange] > frysk.expunit.Expect@219d38 find <<\(fhpd\) >> in <<>>? > frysk.expunit.Expect@219d38 poll for 5000 milliseconds > frysk.expunit.Expect@219d38 poll -> < (fhpd) >> giving < (fhpd) >> > frysk.expunit.Expect@219d38 find <<\(fhpd\) >> in < (fhpd) >>? > frysk.expunit.Expect@219d38 match <<(fhpd) >> > frysk.expunit.Expect@219d38 send < > frysk.expunit.Expect@219d38 find <> in <<>>? > frysk.expunit.Expect@219d38 poll for 5000 milliseconds > frysk.expunit.Expect@219d38 poll -> <> giving <> > frysk.expunit.Expect@219d38 find <> in <>? > frysk.expunit.Expect@219d38 poll for 5000 milliseconds > frysk.expunit.Expect@219d38 poll -> < >>> giving <>> >>> > frysk.expunit.Expect@219d38 find <> in < >>> ? >>> From swagiaal@redhat.com Wed Aug 29 20:45:00 2007 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Wed, 29 Aug 2007 20:45:00 -0000 Subject: elfutils import In-Reply-To: <20070827202033.D62924D05BE@magilla.localdomain> References: <20070827202033.D62924D05BE@magilla.localdomain> Message-ID: <46D5DAD1.8050807@redhat.com> Roland McGrath wrote: > That diff was really not useful. Please post the diff between what you > have in the frysk tree and the corresponding vanilla elfutils source. > Roland, My mistake. This branch (sami-elfutils_129-merge-20070827-branch) now contains the vanila elfutils sources plus frysk changes to elfutils. I attached a diff showing thos changes. Sami -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: frysk_changes URL: From ajocksch@redhat.com Wed Aug 29 22:30:00 2007 From: ajocksch@redhat.com (Adam Jocksch) Date: Wed, 29 Aug 2007 22:30:00 -0000 Subject: Trouble with frysk.expunit.Expect and fhpd In-Reply-To: <46D5C28C.20403@redhat.com> References: <46D5BD8F.8070003@redhat.com> <46D5C28C.20403@redhat.com> Message-ID: <46D5F37D.8040909@redhat.com> Andrew Cagney wrote: > Adam Jocksch wrote: >> I've been trying to re-tool frysk.hpd.TestDisplayCommand to use >> funit-rt-varchange instead of hpd-c (bug #4951). However, the expect >> script fails when fhpd doesn't behave as expected when adding a >> breakpoint. I've attached the revised version of >> TestDisplayCommand.java as well as the log created by ./TestRunner >> -log frysk=FINE frysk.hpd.TestDisplayCommand. Running >> 'frysk/bindir/fhpd frysk/pkglibdir/funit-rt-varchange' from the >> frysk-core directory produces the expected results; it's only under >> Expect that fhpd is functioning strangely. >> > see: http://sourceware.org/bugzilla/show_bug.cgi?id=4914 and 4919 ; > missting synchronization in fhpd can lead to expunit can feeding it > commands to fast. Try adding a sleep(5) after the run, but before the > breakpoint is set; something like: > > e.send("run " + Config.getPkgLibFile("funit-stepping-asm") + > "\n"); > e.expect(5, "Attached.*\n" + prompt); > > // Remove this - #4919 and #4914. > try { Thread.sleep(2000); } catch (Exception e) {} > > e.send("break #" + source + "#" + startLine + "\n"); > e.expect("breakpoint.*\n" + prompt); > > if this lets it work, keep the sleep and mark the test as > unresolved(4914). We can then still run it with --unresolved. > Awesome, that worked like a charm. It also fixed the error with creating displays through expect. However in my testcase I don't send run to fhpd, rather I execute fhpd with the executable as an argument. For right now TestDisplayCommands is marked unresolved(4941) and passes and I have filed bz#4982 re: removing the sleep statements. If need be I can create a new bug for this race condition and change TestDisplayCommands appropriately. From pearly.zhao@oracle.com Thu Aug 30 03:51:00 2007 From: pearly.zhao@oracle.com (Zhao Shujing) Date: Thu, 30 Aug 2007 03:51:00 -0000 Subject: [patch] Fix bugs of memory window Message-ID: <1188446167.7327.22.camel@linux-pzhao.site> Hi, This patch is to fix bug #4617 and other bugs of memory window. - Fixed bug converting to bin and hex when memory value is negative number. - Fixed bug to get octal number by convert from hex. - Setting the font to fixed-width font "monospace 10" - Adding leading zero for all of bin, oct and hex. - Adding prefix zero to octal number. Any suggestions are welcomed Pearly -------------- next part -------------- A non-text attachment was scrubbed... Name: memwin0830.patch Type: text/x-patch Size: 3322 bytes Desc: URL: From cagney@redhat.com Thu Aug 30 13:59:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 30 Aug 2007 13:59:00 -0000 Subject: [patch] Fix bugs of memory window In-Reply-To: <1188446167.7327.22.camel@linux-pzhao.site> References: <1188446167.7327.22.camel@linux-pzhao.site> Message-ID: <46D6CD2F.9090409@redhat.com> Zhao Shujing wrote: > Hi, > > This patch is to fix bug #4617 and other bugs of memory window. > - Fixed bug converting to bin and hex when memory value is negative > number. > - Fixed bug to get octal number by convert from hex. > - Setting the font to fixed-width font "monospace 10" > - Adding leading zero for all of bin, oct and hex. > - Adding prefix zero to octal number. > > Any suggestions are welcomed > > Pearly, perhaps check the constructor <> as in <> it will convert the big-endian byte array directly into an unsigned BigInteger letting you use more of: > + oct = bihex.toString(8); and, beyond needing to zero-pad, may make things even simpler. Andrew From kris.van.hees@oracle.com Thu Aug 30 20:20:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Thu, 30 Aug 2007 20:20:00 -0000 Subject: Chris' utracer Message-ID: <20070830201919.GF22263@oracle.com> After doing a checkout of the frysk-utrace module to haved a look at it, I notived that it does not have any form of license or copyright statement listed. The only hint at a license is in the kernel module license specification. Is that intentional, or oversight? Cheers, Kris From cagney@redhat.com Thu Aug 30 20:35:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 30 Aug 2007 20:35:00 -0000 Subject: elfutils import In-Reply-To: <46D5DAD1.8050807@redhat.com> References: <20070827202033.D62924D05BE@magilla.localdomain> <46D5DAD1.8050807@redhat.com> Message-ID: <46D72A3D.2030804@redhat.com> Sami Wagiaalla wrote: > Roland McGrath wrote: >> That diff was really not useful. Please post the diff between what you >> have in the frysk tree and the corresponding vanilla elfutils source. >> > Roland, > > My mistake. This branch (sami-elfutils_129-merge-20070827-branch) now > contains the vanila elfutils sources plus frysk changes to elfutils. I > attached a diff showing thos changes. > > Sami Thanks! Working through this I found these problems: > GLOBAL(large_global_at_small_global) > GLOBAL(small_global_at_large_global) > STORE(REG0,REG0) <---- HERE > NO_OP > SIZE(small_global_at_large_global) > NO_OP > SIZE(large_global_at_small_global) this isn't "stable" the first of those symbols is choose. > # A global symbol that has zero size. > GLOBAL(global_st_size_0) > LOAD_IMMED_BYTE (REG0, 0) > STORE (REG0, REG0) <---- HERE > NO_OP this symbol can be missed entirely because min_label is > global_st_size_0. > # A global symbol, with size, that contains a nested global and local > # symbols each also with sizes. > GLOBAL(global_outer) > STORE(REG0, REG0) > NO_OP > LOCAL(local_in_global) > STORE (REG0, REG0) <----- HERE > NO_OP > SIZE(local_in_global) > .Lglobal_outer: > STORE (REG0, REG0) > NO_OP > SIZE(global_outer) this isn't stable, the second of local_in_global and global_outer is chosen. I've attached a context diff of up-stream vs local (they are sufficiently different to make a unified diff harder to read). I'll see about mearing that !section and !file test. Andrew -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diffs URL: From cmoller@redhat.com Thu Aug 30 23:15:00 2007 From: cmoller@redhat.com (Chris Moller) Date: Thu, 30 Aug 2007 23:15:00 -0000 Subject: Chris' utracer In-Reply-To: <20070830201919.GF22263@oracle.com> References: <20070830201919.GF22263@oracle.com> Message-ID: <46D74F42.6060303@redhat.com> Kris Van Hees wrote: > After doing a checkout of the frysk-utrace module to haved a look at it, I > notived that it does not have any form of license or copyright statement > listed. The only hint at a license is in the kernel module license > specification. > > Is that intentional, or oversight? > It's an oversight, but it's still very much alpha-level code and not intended for general distribution. cm > Cheers, > Kris > -- Chris Moller Java: the blunt scissors of programming languages. -- Dave Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From kris.van.hees@oracle.com Thu Aug 30 23:31:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Thu, 30 Aug 2007 23:31:00 -0000 Subject: Chris' utracer In-Reply-To: <46D74F42.6060303@redhat.com> References: <20070830201919.GF22263@oracle.com> <46D74F42.6060303@redhat.com> Message-ID: <20070830233009.GH22263@oracle.com> On Thu, Aug 30, 2007 at 07:14:10PM -0400, Chris Moller wrote: > Kris Van Hees wrote: > > After doing a checkout of the frysk-utrace module to haved a look at it, I > > notived that it does not have any form of license or copyright statement > > listed. The only hint at a license is in the kernel module license > > specification. > > > > Is that intentional, or oversight? > > It's an oversight, but it's still very much alpha-level code and not > intended for general distribution. Thanks for clearing that up. I definitely wasn't thinking about any form of distribution or other use beyond frysk. It just seemed odd to not have any copyright or license information on the files, hence the question. Having it in there will avoid any confusion about the code's status in a public repository. Cheers, Kris From cmoller@redhat.com Fri Aug 31 00:38:00 2007 From: cmoller@redhat.com (Chris Moller) Date: Fri, 31 Aug 2007 00:38:00 -0000 Subject: Chris' utracer In-Reply-To: <20070830233009.GH22263@oracle.com> References: <20070830201919.GF22263@oracle.com> <46D74F42.6060303@redhat.com> <20070830233009.GH22263@oracle.com> Message-ID: <46D762EB.9040509@redhat.com> I just added a copyright notice to each of the files and committed the lot. cm Kris Van Hees wrote: > On Thu, Aug 30, 2007 at 07:14:10PM -0400, Chris Moller wrote: > >> Kris Van Hees wrote: >> >>> After doing a checkout of the frysk-utrace module to haved a look at it, I >>> notived that it does not have any form of license or copyright statement >>> listed. The only hint at a license is in the kernel module license >>> specification. >>> >>> Is that intentional, or oversight? >>> >> It's an oversight, but it's still very much alpha-level code and not >> intended for general distribution. >> > > Thanks for clearing that up. I definitely wasn't thinking about any form of > distribution or other use beyond frysk. It just seemed odd to not have any > copyright or license information on the files, hence the question. Having > it in there will avoid any confusion about the code's status in a public > repository. > > Cheers, > Kris > -- Chris Moller Java: the blunt scissors of programming languages. -- Dave Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From pearly.zhao@oracle.com Fri Aug 31 06:30:00 2007 From: pearly.zhao@oracle.com (Zhao Shujing) Date: Fri, 31 Aug 2007 06:30:00 -0000 Subject: [patch] Fix bugs of memory window In-Reply-To: <46D6CD2F.9090409@redhat.com> References: <1188446167.7327.22.camel@linux-pzhao.site> <46D6CD2F.9090409@redhat.com> Message-ID: <1188542102.15120.1.camel@linux-pzhao.site> Thanks Andrew. The patch is updated. On Thu, 2007-08-30 at 09:59 -0400, Andrew Cagney wrote: > Zhao Shujing wrote: > > Hi, > > > > This patch is to fix bug #4617 and other bugs of memory window. > > - Fixed bug converting to bin and hex when memory value is negative > > number. > > - Fixed bug to get octal number by convert from hex. > > - Setting the font to fixed-width font "monospace 10" > > - Adding leading zero for all of bin, oct and hex. > > - Adding prefix zero to octal number. > > > > Any suggestions are welcomed > > > > > Pearly, perhaps check the constructor <> as > in <> it will convert the big-endian byte array > directly into an unsigned BigInteger letting you use more of: > > > + oct = bihex.toString(8); > and, beyond needing to zero-pad, may make things even simpler. > > Andrew > -------------- next part -------------- A non-text attachment was scrubbed... Name: memwin0830.patch Type: text/x-patch Size: 3294 bytes Desc: not available URL: From cagney@redhat.com Tue Sep 4 18:46:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 04 Sep 2007 18:46:00 -0000 Subject: meeting 2007-09-05 9:30 US-EAST Message-ID: <46DDA804.3000708@redhat.com> Topic is mercurial vs git vs cvs. From cagney@redhat.com Tue Sep 4 19:05:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 04 Sep 2007 19:05:00 -0000 Subject: meeting 2007-09-05 9:30 US-EAST In-Reply-To: <46DDA804.3000708@redhat.com> References: <46DDA804.3000708@redhat.com> Message-ID: <46DDAC7F.2080604@redhat.com> Some status: Type, value, variable, ... fixes and improvements; this is to stop frysk reporting , for instance: scox: adding frysk.debuginfo.TypeEntry and TestTypeEntry which parse recursive types in DIE information sami: finished support for inline scopes; addressing performance problems; working to simplify the DebugInfoEvaluator so it uses that (and does proper scope lookups). teresa: location expressions; in particular support for DW_OP_piece cagney: overhauled type system in frysk.value; supports the DWARF types that C/C++ can define -- rick&phil: Work a frysk.value.dead.Exe{Host,Task,Proc}; this is part of getting: (fhpd) load executable (fhpd) print i work. tim: making the stepping-engine and hpd synchronized so that races such as typing: (hpd) run (hpd) break main too fast wouldn't work. mark: importing libunwind, bringing in the ppc stuff and other fixes; ready for working on .debug_frame. This is so that back-traces are far more robust. From timoore@redhat.com Wed Sep 5 10:15:00 2007 From: timoore@redhat.com (Tim Moore) Date: Wed, 05 Sep 2007 10:15:00 -0000 Subject: meeting 2007-09-05 9:30 US-EAST In-Reply-To: <46DDA804.3000708@redhat.com> References: <46DDA804.3000708@redhat.com> Message-ID: <46DE81CA.3060909@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Cagney wrote: > Topic is mercurial vs git vs cvs. > http://lwn.net/Articles/246381/ is interesting on the subject of git repository styles, distributed vs centralized, etc. Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG3oHKeDhWHdXrDRURAgNSAKDdIL7L5iwaqkFaKZdNlHDoL5ekLgCdEg8X jOmaFFsye3EBAYSvhYWyDkM= =M7/6 -----END PGP SIGNATURE----- From mark@klomp.org Wed Sep 5 13:14:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Wed, 05 Sep 2007 13:14:00 -0000 Subject: cvs, hg, git, etc. Re: meeting 2007-09-05 9:30 US-EAST In-Reply-To: <46DE81CA.3060909@redhat.com> References: <46DDA804.3000708@redhat.com> <46DE81CA.3060909@redhat.com> Message-ID: <1188998040.3813.34.camel@dijkstra.wildebeest.org> On Wed, 2007-09-05 at 12:15 +0200, Tim Moore wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Andrew Cagney wrote: > > Topic is mercurial vs git vs cvs. > > > http://lwn.net/Articles/246381/ is interesting on the subject of git repository > styles, distributed vs centralized, etc. Here is a super short summary of git vs hg: http://blog.experimentalworks.net/archives/38-Git-vs.-Mercurial.html it has one big flaw in that it missed named branches in hg: http://hgbook.red-bean.com/hgbookch8.html (The Mercurial book is pretty good btw, go read it cover to cover!) Personally I am actually fine with staying with cvs. I like to tinker with different cms like setting up the hg and trac clones. I try to use them locally, but I cannot say I am expert enough to recommend one. The real issues to discuss imho are: - Does anybody have a good workflow in mind if we switch to any dcms? Although I can use it for simple stuff myself I don't really know how any of the more advantaged usages (vendor branch tracking for example) really work out. - Is having the whole group learn a complete new set of tools and concepts really that beneficial over just staying with cvs? - What does sourceware actually support? - Who wants to maintain the system/set it up/keep track of issues/etc. Although it isn't that hard, I could setup the hg and trac mirror over the weekend, it is real work and needs someone to babysit it the first few weeks to help everybody get up to speed and make sure it doesn't fall over in production use. Cheers, Mark From elena.zannoni@oracle.com Wed Sep 5 14:22:00 2007 From: elena.zannoni@oracle.com (Elena Zannoni) Date: Wed, 05 Sep 2007 14:22:00 -0000 Subject: meeting notes 20070905 Message-ID: <46DEBB8C.6090608@oracle.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: frysk-20070905 URL: From pmuldoon@redhat.com Wed Sep 5 14:41:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Wed, 05 Sep 2007 14:41:00 -0000 Subject: meeting notes 20070905 In-Reply-To: <46DEBB8C.6090608@oracle.com> References: <46DEBB8C.6090608@oracle.com> Message-ID: <46DEBFF9.9060807@redhat.com> Elena Zannoni wrote: Some further notes. Minutes as an attachment make in-line comments painful :( > Frysk meeting 2007-09-05 > > Version control systems discussions > > Tim Andrew Elena Stan Mark Sami [who else?] > Phil > Do people that prefer strongly one system have played around with the > others as well? > > Tim --> likes Git, hasn't tried Hg > Mark --> Hg Phil --> either, as long as it is not CVS. We have decades of combined CVS experience, yet there are still mistakes made daily. Some of which take hours and hours to recover from. At some point have to look at the tool, and not the developer and perhaps think that a newer, better one is needed. Personally (further down) there are lots of projects moving to DCM. Including OpenJDK, Mozilla, Kernel, ASLA, Xen, RPM, etc etc to name a few. I find the "stay with CVS as it is known" a bit of a false argument. Borked and old != better. > Plugins: cvs plugin in eclipse. No other plugins for eclipse. > cvs module in emacs as well. no emacs modes for git and Hg. Incorrect at least for Mercurial: http://www.selenic.com/mercurial/wiki/index.cgi/OtherTools No idea about GiT though I am sure Tim will fill in. > Advantage over cvs is that one can recover easily from erroneous > commits, because of the changesets. Active developer community, saner interface (goodbye to positional switches!). Trac and Maven integration. > What projects we know of are using Git and which ones are using Hg? > > Git: kernel, libunwind > Hg: icedtea, openjdk, mozilla For Mercurial http://www.selenic.com/mercurial/wiki/index.cgi/ProjectsUsingMercurial I'll fill all this data into the webpage, too. Regards Phil From pearly.zhao@oracle.com Thu Sep 6 09:02:00 2007 From: pearly.zhao@oracle.com (Zhao Shujing) Date: Thu, 06 Sep 2007 09:02:00 -0000 Subject: [patch] Fix bug 4613, 4621, 4622 Message-ID: <1189069686.4967.7.camel@linux-pzhao.site> Hi, This patch is to fix bug 4613, 4621 and 4622. About bug 4613: Invalid addresses (outside of any accessible segment) cause a hang, I choose to reset the value to lastKnownFrom/lastKnownTo when fromSpin/toSpin try to access inaccessible address. Best Regards Pearly -------------- next part -------------- A non-text attachment was scrubbed... Name: 46214622.patch Type: text/x-patch Size: 9335 bytes Desc: URL: From cagney@redhat.com Thu Sep 6 13:40:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 06 Sep 2007 13:40:00 -0000 Subject: Easier HPD expect methods Message-ID: <46E0036D.7030907@redhat.com> FYI, For code wanting to test HPD interactions (as found in frysk.hpd.Test*) I've added the class frysk.hpd.HpdTestbed which extends Expect. This class both creates an instance of the HPD wrapped up in Expect and provides easier / more friendly expect methods vis: -> they detect wrong-output+PROMPT; no longer is there a 5 second timeout before things fail -> the failure message includes what was expected and what was in the buffer - easier to debug For instance: public void testUnattached() { e = new HpdTestbed(); // Add with no process; shouldn't crash. e.sendCommandExpectPrompt("print 2+2", "5\r\n"); } $ ./TestRunner frysk.hpd.TestPrint.testUnattached Running testUnattached(frysk.hpd.TestPrint) ...FAIL junit.framework.AssertionFailedError: sent: expecting: <5 > got: Note that this class isn't intended for testing HPD invocation, or option parser (as done by the tests in frysk.bindir.TestHpd); as some point this class is going to get changed to run HPD as a thread in TestRunner. Andrew From cagney@redhat.com Thu Sep 6 13:54:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 06 Sep 2007 13:54:00 -0000 Subject: Please, keep it private Message-ID: <46E0069C.2020104@redhat.com> Hi, This change is interesting: * TestValue.java: Make all fields private. (longBEUnsignedType): Delete. (intBEUnsignedType): Delete. (shortBEUnsignedType): Delete. (byteBEUnsignedType): Delete. (floatBEType): Delete. (doubleBEType): Delete. (longUnsignedType): Delete. (intUnsignedType): Delete. (shortUnsignedType): Delete. (byteUnsignedType): Delete. notice the consequence, of making those fields private. When adding a field please start with the most private scope possible, even make it final. Similarly, delay adding either a getEr or setEr method until it is clear that it is needed. If we remember to do this, refactoring is relatively easy (dead variables are even identified by the compiler). If we don't do this we're left with an accumulating pile of [likely] dead fields and methods. something none of us want :-( :-) Andrew From kris.van.hees@oracle.com Fri Sep 7 02:22:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Fri, 07 Sep 2007 02:22:00 -0000 Subject: Patch for TearDownProcess Message-ID: <20070907022100.GK22263@oracle.com> The attached patch has been commitedfor TearDownProcess, to handle various cases of TestRunner hanging due to stray child process. The bugzilla ticket that handles this case is #4996. The symptom was typically that a test execution started a child process, but failed to register that process. This left the process hanging, sometimes in a utrace call, causing the next invocation of tearDown() to hang on the waitAll request because the wait was remaining in effect due to a stuck process. The attached patch *does* open the possibility that a stray process may remain after tearDown() has been executed if e.g. a process termination causes another process to be created, etc... However, that will not cause a testsuite hang. It is also not expected to pose a problem with the further execution of the testsuite (in fact, it is very likely to get cleaned up during the tearDown() of the next test). The change has been tested multiple times to verify that it does not cause any regressions. Cheers, Kris -------------- next part -------------- --- TearDownProcess.java-orig 2007-09-06 17:37:05.000000000 -0400 +++ TearDownProcess.java 2007-09-06 20:07:51.000000000 -0400 @@ -1,5 +1,6 @@ // This file is part of the program FRYSK. // +// Copyright 2007 Oracle Corporation. // Copyright 2005, 2006, 2007, Red Hat Inc. // // FRYSK is free software; you can redistribute it and/or modify it @@ -43,15 +44,16 @@ import java.util.logging.Level; import java.util.Set; import java.util.HashSet; +import frysk.junit.TestCase; import frysk.sys.Errno; import frysk.sys.Sig; import frysk.sys.Signal; import frysk.sys.Wait; import frysk.sys.proc.ProcBuilder; import frysk.sys.ProcessIdentifier; -import java.util.Iterator; import frysk.sys.Ptrace; import frysk.sys.WaitBuilder; +import frysk.sys.SignalBuilder; /** * Framework for cleaning up temporary processes created as part of a @@ -160,7 +162,7 @@ * continued. Work around this by first sending all tasks a * continue ... */ - private static ProcessIdentifier capturedSendDetachContKill (ProcessIdentifier pid) + private static boolean capturedSendDetachContKill (ProcessIdentifier pid) { // Do the detach try { @@ -181,11 +183,10 @@ log("tkill -CONT", pid, "(failed - ESRCH)\n"); } // Finally send it a kill to finish things off. - capturedSendTkill(pid); - return pid; + return capturedSendTkill(pid); } - private static ProcessIdentifier capturedSendDetachContKill (int pid) + private static boolean capturedSendDetachContKill (int pid) { return capturedSendDetachContKill (new ProcessIdentifier (pid)); } @@ -195,9 +196,11 @@ // Make a preliminary pass through all the registered // pidsToKillDuringTearDown trying to simply kill // each. Someone else may have waited on their deaths already. - for (Iterator i = pidsToKillDuringTearDown.iterator(); i.hasNext();) { - ProcessIdentifier child = (ProcessIdentifier) i.next(); - capturedSendTkill(child); + Object[] pidsToKill = pidsToKillDuringTearDown.toArray(); + for (int i = 0; i < pidsToKill.length; i++) { + ProcessIdentifier child = (ProcessIdentifier) pidsToKill[i]; + if (!capturedSendTkill(child)) + pidsToKillDuringTearDown.remove(child); } // Go through all registered processes / tasks adding any of @@ -214,16 +217,18 @@ // Iterate over a copy of the tids's collection as the // missingTidsToKillDuringTearDown may modify the underlying // collection. - Object[] pidsToKill = pidsToKillDuringTearDown.toArray(); + pidsToKill = pidsToKillDuringTearDown.toArray(); for (int i = 0; i < pidsToKill.length; i++) { ProcessIdentifier child = (ProcessIdentifier) pidsToKill[i]; missingTidsToKillDuringTearDown.construct(child); } // Blast all the processes for real. - for (Iterator i = pidsToKillDuringTearDown.iterator(); i.hasNext();) { - ProcessIdentifier child = (ProcessIdentifier) i.next(); - capturedSendDetachContKill(child); + pidsToKill = pidsToKillDuringTearDown.toArray(); + for (int i = 0; i < pidsToKill.length; i++) { + ProcessIdentifier child = (ProcessIdentifier) pidsToKill[i]; + if (!capturedSendDetachContKill(child)) + pidsToKillDuringTearDown.remove(child); } // Drain the wait event queue. This ensures that: there are @@ -235,77 +240,77 @@ // For attached tasks, which will generate non-exit wait // events (clone et.al.), the task is detached / killed. // Doing that frees up the task so that it can run to exit. - try { - while (! pidsToKillDuringTearDown.isEmpty()) { - log("waitAll -1 ...."); - Wait.waitAll(-1, new WaitBuilder() { - public void cloneEvent (int pid, int clone) - { - capturedSendDetachContKill(pid); - } - - public void forkEvent (int pid, int child) - { - capturedSendDetachContKill(pid); - } - - public void exitEvent (int pid, boolean signal, int value, - boolean coreDumped) - { - capturedSendDetachContKill(pid); - // Do not remove PID from - // pidsToKillDuringTearDown list; need to - // let the terminated event behind it - // bubble up. - } - - public void execEvent (int pid) - { - capturedSendDetachContKill(pid); - } - - public void syscallEvent (int pid) - { - capturedSendDetachContKill(pid); - } - - public void stopped (int pid, int signal) - { - capturedSendDetachContKill(pid); - } - - private void drainTerminated (int pid) - { - // To be absolutly sure, again make - // certain that the thread is detached. - ProcessIdentifier id = capturedSendDetachContKill(pid); - // True pidsToKillDuringTearDown can have - // a second exit status behind this first - // one, drain that also. Give up when - // this PID has no outstanding events. - log("Wait.drain", id, "\n"); - id.blockingDrain (); - // Hopefully done with this PID. - pidsToKillDuringTearDown.remove(id); - } - - public void terminated (int pid, boolean signal, - int value, - boolean coreDumped) - { - drainTerminated(pid); - } - - public void disappeared (int pid, Throwable w) - { - // The task vanished somehow, drain it. - drainTerminated(pid); - } - }); - } - } - catch (Errno.Echild e) { - // No more events. + if (!pidsToKillDuringTearDown.isEmpty()) { + log("waitAll " + pidsToKillDuringTearDown + " ...."); + Wait.waitAll( + TestCase.getTimeoutMilliseconds(), + new WaitBuilder() { + public void cloneEvent (int pid, int clone) + { + capturedSendDetachContKill(pid); + } + + public void forkEvent (int pid, int child) + { + capturedSendDetachContKill(pid); + } + + public void exitEvent (int pid, boolean signal, int value, + boolean coreDumped) + { + capturedSendDetachContKill(pid); + // Do not remove PID from + // pidsToKillDuringTearDown list; need to + // let the terminated event behind it + // bubble up. + } + + public void execEvent (int pid) + { + capturedSendDetachContKill(pid); + } + + public void syscallEvent (int pid) + { + capturedSendDetachContKill(pid); + } + + public void stopped (int pid, int signal) + { + capturedSendDetachContKill(pid); + } + + private void drainTerminated (int pid) + { + // To be absolutly sure, again make + // certain that the thread is detached. + capturedSendDetachContKill(pid); + ProcessIdentifier id = new ProcessIdentifier (pid); + // True pidsToKillDuringTearDown can have + // a second exit status behind this first + // one, drain that also. Give up when + // this PID has no outstanding events. + log("Wait.drain", id, "\n"); + id.blockingDrain (); + // Hopefully done with this PID. + pidsToKillDuringTearDown.remove(id); + } + + public void terminated (int pid, boolean signal, int value, + boolean coreDumped) + { + drainTerminated(pid); + } + + public void disappeared (int pid, Throwable w) + { + // The task vanished somehow, drain it. + drainTerminated(pid); + } + }, + new SignalBuilder() { + public void signal(Sig sig) {} + }); } // Drain all the pending signals. Note that the process of killing From timoore@redhat.com Fri Sep 7 07:38:00 2007 From: timoore@redhat.com (Tim Moore) Date: Fri, 07 Sep 2007 07:38:00 -0000 Subject: meeting notes 20070905 In-Reply-To: <46DEBB8C.6090608@oracle.com> References: <46DEBB8C.6090608@oracle.com> Message-ID: <46E0FFE9.1070104@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Elena Zannoni wrote: > Impact on the history before the switch: it is maintained. No loss of > info there doing the import. > > Import into git from cvs preserved branches. Tim hasn't ported the > history though. Git got confused at some branch merge points in the > history. Tim corrected by hand. Since the first import there were no > more conflicts. Tim does imports/resyncs twice a day, never seen > further problems. Mark observed some problems also when he did import > imnto Hg. > This isn't quite right. I did import all the history into my mirror. I have had to make some after-the-fact fix-ups on a few occasions to get my git repository back in sync with the CVS tree, but I think this can be attributed in part to the abusive way in which I'm doing the mirroring. I use parsecvs to construct a new git repo from scratch when I update the mirror; it's somewhat miraculous (to me :) that the second repo, in which I've put the symbolic links and other fixes, continues to work after this. There are certainly better ways to do CVS mirroring, but I stuck with the program that worked for me and haven't had the bandwidth to search for a better way. In any event, the mirroring of a CVS tree isn't relevant to a discussion about which system to change to. Last night I did an experiment using parsecvs to do the import, then changing the CVS modules file in order to check out the "raw" directories in our tree. The *only* differences I found between the CVS checkout and the git checkout were in libunwind which I knew was a problem because of its origins on the vendor branch. So, I think we can be confident that an import will preserve our history. It may be best to put our external dependencies in a different "sub repository," but in any event I'm confident that we can preserve the history of the libunwind / elfutils commits too. > Tim kept 2 repos, one using symbolic links. Mark had to do the same > stuff in Hg. Frysk-common is the module that presented problems. I encountered an interesting problem with my symbolic link commit that makes the source tree look like what the build system expects. One nice feature of git is "git bisect," which allows you to do a binary search of the history, with checkouts, to find the point in time when a bug was introduced. If the tree is not buildable without a later patch, this process becomes awkward... you can do the same machinations by hand and apply the symbolic links patch at each step, but that's a pain. So, it may be worthwhile to rewrite history to introduce the symbolic links -- or other fixup -- early in time. > > Expertize in house with each system? Oracle has a few git projects > already and no Hg. How about Rht? Jeff Garzik is the author of Kernel Hackers' Guide to git http://linux.yyz.us/git-howto.html Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG4P/peDhWHdXrDRURAhg4AKDacpUnGrWOZzTPTDg46b3l+jQCDACgkTDN tueU+/O1NQYOpZjRUyQjOfs= =fkHh -----END PGP SIGNATURE----- From cagney@redhat.com Fri Sep 7 13:31:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 07 Sep 2007 13:31:00 -0000 Subject: Patch for TearDownProcess In-Reply-To: <20070907022100.GK22263@oracle.com> References: <20070907022100.GK22263@oracle.com> Message-ID: <46E15274.5020400@redhat.com> Kris Van Hees wrote: > The attached patch *does* open the possibility that a stray process may remain > after tearDown() has been executed if e.g. a process termination causes another > process to be created, etc... However, that will not cause a testsuite hang. > It is also not expected to pose a problem with the further execution of the > testsuite (in fact, it is very likely to get cleaned up during the tearDown() > of the next test). > Unfortunately this isn't theoretical. On a slower f5 machine; this happens consistently; invalidating test results. Given the choices between a potential test-suite hang, and tear-down leaving waitpid events around, the decision was made in favor of the latter. That decision hasn't changed. Having the test run hang, is a lesser evil then the test-suite continuing but producing bogus results.. I restored the old behavior; and then added a timeout. It currently logs a message, I suspect it should abandon the test run, since the problem state hasn't gone away. Andrew From kris.van.hees@oracle.com Fri Sep 7 14:30:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Fri, 07 Sep 2007 14:30:00 -0000 Subject: Patch for TearDownProcess In-Reply-To: <46E15274.5020400@redhat.com> References: <20070907022100.GK22263@oracle.com> <46E15274.5020400@redhat.com> Message-ID: <20070907142827.GL22263@oracle.com> On Fri, Sep 07, 2007 at 09:30:28AM -0400, Andrew Cagney wrote: > Kris Van Hees wrote: >> The attached patch *does* open the possibility that a stray process may >> remain >> after tearDown() has been executed if e.g. a process termination causes >> another >> process to be created, etc... However, that will not cause a testsuite >> hang. >> It is also not expected to pose a problem with the further execution of >> the >> testsuite (in fact, it is very likely to get cleaned up during the >> tearDown() >> of the next test). >> > Unfortunately this isn't theoretical. On a slower f5 machine; this happens > consistently; invalidating test results. The information you added to ticket 4996 doesn't quite show anything that indicates that this is a problem with my patch. In the future, could you at least add output after a -c FINEST run or something, to ensure there is relevant information there to help work out a fix? > Given the choices between a potential test-suite hang, and tear-down > leaving waitpid events around, the decision was made in favor of the > latter. That decision hasn't changed. Having the test run hang, is a > lesser evil then the test-suite continuing but producing bogus results.. > I restored the old behavior; and then added a timeout. It currently logs a > message, I suspect it should abandon the test run, since the problem state > hasn't gone away. Obviously, there can be a difference of opinion on this matter, and I believe that reversing this patch without any consideration for the matter it aims at solving is useless. You deliberately restore a problem behaviour. Why? It would have been more constructive to open a bug about the problem you have encountered, and have that problem resolved, so that in the end we have a fully working testsuite that doesn't need a tradeoff between hanging and stray waitpid events. Finally, given that you use FC5 as your reference platform here, perhaps you could add it to the automated test system (i.e. have it submit results there) so that test coverage can be expended to that release as well (especially since it seems to uncover some problems that other systems do not - assuming of course that no kernel issues are involved). Cheers, Kris From elena.zannoni@oracle.com Fri Sep 7 18:39:00 2007 From: elena.zannoni@oracle.com (Elena Zannoni) Date: Fri, 07 Sep 2007 18:39:00 -0000 Subject: Patch for TearDownProcess In-Reply-To: <46E15274.5020400@redhat.com> References: <20070907022100.GK22263@oracle.com> <46E15274.5020400@redhat.com> Message-ID: <46E19AB5.30104@oracle.com> Andrew Cagney wrote: > Unfortunately this isn't theoretical. On a slower f5 machine; this > happens consistently; invalidating test results. Can you post more information about the things you are seeing? Whatever is in the bugzilla does not have enough details to diagnose the problem. At this point you are the only one knowing what is going on in your tests, it would be nice if you could share the information with the rest of the team. If nothing else, just out of respect for the work that Kris put into finding the cause of the hangs in the first place, explaining that to you last night on irc and writing a patch. If the patch exposed other problems, a civil procedure is to discuss things with the patch author instead of steamrolling your changes in, obliterating other's people work. > > Given the choices between a potential test-suite hang, and tear-down > leaving waitpid events around, the decision was made in favor of the > latter. That decision hasn't changed. Having the test run hang, is a > lesser evil then the test-suite continuing but producing bogus results.. Who made that decision? Can you explain why hangs in the testsuite (which have been there for a long time) are reasonable to have? I would think that an intelligent person and a hard core proponent of extreme programming and other formal development methods like yourself would want to put a big emphasis on the QA of this project, so I am sure missing something here. > I restored the old behavior; and then added a timeout. It currently > logs a message, I suspect it should abandon the test run, since the > problem state hasn't gone away. > I don't think that's what you did. You reimplemented Kris change. From pearly.zhao@oracle.com Wed Sep 12 08:05:00 2007 From: pearly.zhao@oracle.com (Zhao Shujing) Date: Wed, 12 Sep 2007 08:05:00 -0000 Subject: [patch] Accept symbolic addresses in spin button, bug 4673. Message-ID: <1189584690.4843.23.camel@linux-pzhao.site> Hi, This patch can make the disassembly/memory window accept symbol name in spin Button. Here is what it does: - When input a available symbol name at fromBox, the window would display the disassembly/memory of this symbol. The fromBox/fromSpin would be set the start address of this symbol and the toBox/toSpin would be set the end address of this symbol. - When input a available symbol name at toBox, it would do as same as when input at fromBox. - When input a unavailable symbol name, the fromBox/fromSpin or toBox/toSpin would be reset to the lastKnownFrom or lastKnownTo. Any suggestions are welcomed. Pearly Zhao -------------- next part -------------- A non-text attachment was scrubbed... Name: 4673.patch Type: text/x-patch Size: 17554 bytes Desc: URL: From PEARLY.ZHAO@ORACLE.COM Wed Sep 12 13:33:00 2007 From: PEARLY.ZHAO@ORACLE.COM (PEARLY.ZHAO@ORACLE.COM) Date: Wed, 12 Sep 2007 13:33:00 -0000 Subject: [patch] Accept symbolic addresses in spin button, bug 4673. In-Reply-To: <1189584690.4843.23.camel@linux-pzhao.site> References: <1189584690.4843.23.camel@linux-pzhao.site> Message-ID: <17474866.1189604007745.JavaMail.oracle@acsmt303.oracle.com> Actually, retrieving symbol addresses in the classes implementing the disssembly and memory windows is a wrong way to implement this functionality. Maybe it should be designed at core. The classes handling the windows merely use it to obtain the information. Pearly > Hi, > > This patch can make the disassembly/memory window accept symbol > name in > spin Button. > > Here is what it does: > - When input a available symbol name at fromBox, the window > would > display the disassembly/memory of this symbol. The fromBox/fromSpin > would be set the start address of this symbol and the toBox/toSpin > would > be set the end address of this symbol. > - When input a available symbol name at toBox, it would do as > same as > when input at fromBox. > - When input a unavailable symbol name, the fromBox/fromSpin > or > toBox/toSpin would be reset to the lastKnownFrom or lastKnownTo. > > Any suggestions are welcomed. > > Pearly Zhao > > --------Index: disassembler/DisassemblyWindow.java > =================================================================== > RCS file: /cvs/frysk/frysk-gui/frysk/gui/disassembler/DisassemblyWindow.java,v > retrieving revision 1.31 > diff -u -r1.31 DisassemblyWindow.java > --- disassembler/DisassemblyWindow.java 7 Sep 2007 03:18:50 > -0000 1.31 > +++ disassembler/DisassemblyWindow.java 12 Sep 2007 07:43:28 > -0000 > @@ -42,6 +42,7 @@ > package frysk.gui.disassembler; > > import java.util.prefs.Preferences; > +import java.util.LinkedList; > import java.util.List; > import java.util.Iterator; > import java.util.ListIterator; > @@ -74,6 +75,7 @@ > import org.gnu.gtk.event.SpinEvent; > import org.gnu.gtk.event.SpinListener; > > +import frysk.dwfl.DwflCache; > import frysk.gui.common.IconManager; > import frysk.gui.prefs.PreferenceManager; > import frysk.gui.monitor.Saveable; > @@ -81,7 +83,12 @@ > import frysk.proc.Task; > import frysk.stepping.TaskStepEngine; > import frysk.proc.MemoryMap; > +import frysk.symtab.Symbol; > +import frysk.symtab.SymbolFactory; > > +import lib.dwfl.Dwfl; > +import lib.dwfl.DwflModule; > +import lib.dwfl.SymbolBuilder; > import lib.opcodes.Disassembler; > import lib.opcodes.Instruction; > > @@ -379,28 +386,42 @@ > return; > > String str = fromBox.getText(); > - str = str.substring(2); > - try > + > + if (str.startsWith("0x")) > { > - double d = (double) Long.parseLong(str, 16); > - if (!addressAccessible((long)d)) > - fromBox.setText("0x" + Long.toHexString((long) > lastKnownFrom)); > - else > - { > - if (d > lastKnownTo) > + str = str.substring(2); > + try > + { > + double d = (double) Long.parseLong(str, > 16); > + if (!addressAccessible((long)d)) > + fromBox.setText("0x" + Long.toHexString((long) > lastKnownFrom)); > + else > { > - if (lastKnownTo == lastKnownFrom) > - handleFromSpin(lastKnownTo); > + if (d > lastKnownTo) > + { > + if (lastKnownTo == lastKnownFrom) > + handleFromSpin(lastKnownTo); > + else > + fromSpin.setValue(lastKnownTo); > + } > else > - fromSpin.setValue(lastKnownTo); > + fromSpin.setValue(d); > } > - else > - fromSpin.setValue(d); > - } > + } > + catch (NumberFormatException nfe) > + { > + fromBox.setText("0x" + Long.toHexString((long) > lastKnownFrom)); > + } > } > - catch (NumberFormatException nfe) > - { > - fromBox.setText("0x" + Long.toHexString((long) > lastKnownFrom)); > + else > + { > + try > + { > + handleSymbol(str); > + } > + catch (RuntimeException e){ > + fromBox.setText("0x" + Long.toHexString((long) > lastKnownFrom)); > + } > } > } > } > @@ -416,28 +437,41 @@ > return; > > String str = toBox.getText(); > - str = str.substring(2); > - try > + if (str.startsWith("0x")) > { > - double d = (double) Long.parseLong(str, 16); > - if (!(addressAccessible((long)d))) > - toBox.setText("0x" + Long.toHexString((long) > lastKnownTo)); > - else > - { > - if (d < lastKnownFrom) > + str = str.substring(2); > + try > + { > + double d = (double) Long.parseLong(str, > 16); > + if (!(addressAccessible((long)d))) > + toBox.setText("0x" + Long.toHexString((long) > lastKnownTo)); > + else > { > - if (lastKnownFrom == lastKnownTo) > - handleToSpin(lastKnownFrom); > + if (d < lastKnownFrom) > + { > + if (lastKnownFrom == lastKnownTo) > + handleToSpin(lastKnownFrom); > + else > + toSpin.setValue(lastKnownFrom); > + } > else > - toSpin.setValue(lastKnownFrom); > + toSpin.setValue(d); > } > - else > - toSpin.setValue(d); > - } > + } > + catch (NumberFormatException nfe) > + { > + toBox.setText("0x" + Long.toHexString((long) > lastKnownTo)); > + } > } > - catch (NumberFormatException nfe) > - { > - toBox.setText("0x" + Long.toHexString((long) > lastKnownTo)); > + else > + { > + try > + { > + handleSymbol(str); > + } > + catch (RuntimeException e){ > + toBox.setText("0x" + Long.toHexString((long) > lastKnownTo)); > + } > } > } > } > @@ -539,6 +573,32 @@ > } > this.refreshList(); > } > + > + /** > + * Get the address list from symbol name; > + * @param name > + * @return address list > + */ > + private LinkedList addressesForSymbol(String name) { > + Dwfl dwfl = DwflCache.getDwfl(this.myTask); > + DwflModule[] modules = dwfl.getModules(); > + final LinkedList addrs = new LinkedList(); > + SymbolBuilder builder = new SymbolBuilder() { > + public void symbol(String name, long value, long size, > + int type, int bind, int visibility) { > + addrs.add(new Long(value)); > + } > + }; > + for (int i = 0; i < modules.length; i++) > + { > + DwflModule module = modules[i]; > + module.getSymbolByName(name, builder); > + } > + if (addrs.size() == 0) > + throw new RuntimeException("Couldn't find symbol " + > name); > + else > + return addrs; > + } > /** > * return a boolean indicating whether or not this address > is accessible. > * > @@ -640,16 +700,17 @@ > * By default append rows to the end. > * > * @param i The address to be displayed > + * @param numIns The Instructions that maybe be added > * @param iter The TreeIter representing the row to be > added. > */ > - public synchronized void rowAppend (long i, TreeIter iter) > + public synchronized void rowAppend (long i, int numIns, > TreeIter iter) > { > // if (iter == null) > // iter = model.appendRow(); > > List instructionsList > = diss.disassembleInstructions((long) this.lastKnownTo, > - numInstructions); > + numInstructions+numIns); > Iterator li = instructionsList.listIterator(0); > Instruction ins = (Instruction) li.next(); > > @@ -661,8 +722,10 @@ > this.lastPath.next(); > if (ins != null) > { > - if (li.hasNext()) > + if (li.hasNext()){ > ins = (Instruction) li.next(); > + this.numInstructions++; > + } > else > { > this.toSpin.setValue((double) ins.address); > @@ -858,10 +921,11 @@ > > if (val > this.lastKnownTo) > { > - for (long i = (long) lastKnownTo + 1; i < val + 1; > i++) > - ++this.numInstructions; > + int numIns = 0; > + for (long i = (long) lastKnownTo + 1; i < val + 1; i++) > + ++numIns; > > - rowAppend((long) val, null); > + rowAppend((long) val, numIns, null); > > return; > } > @@ -895,6 +959,48 @@ > refreshList(); > } > } > + > + /** > + * When the box is inputed a symbol, update the displayed > information to the symbol. > + * @param symbolName > + */ > + private synchronized void handleSymbol(String symbolName) > + { > + LinkedList addressList = addressesForSymbol(symbolName); > + long startAddress = ((Long)addressList.getFirst()).longValue(); > + Symbol symbol = SymbolFactory.getSymbol(this.myTask, > startAddress); > + long endAddress = symbol.getAddress() + symbol.getSize(); > + > + List instructionsList > + = diss.disassembleInstructionsStartEnd((long)startAddress, > (long)endAddress); > + Iterator li = instructionsList.listIterator(0); > + int insnum = 1; > + Instruction ins = (Instruction)li.next(); > + this.lastKnownFrom = (double)ins.address; > + while (li.hasNext()){ > + ins = (Instruction)li.next(); > + insnum++; > + } > + this.lastKnownTo = (double)ins.address; > + > + TreeIter iter = this.model.getFirstIter(); > + while (insnum < numInstructions) > + { > + this.model.removeRow(iter); > + this.lastPath.previous(); > + numInstructions--; > + } > + while(insnum > numInstructions) > + { > + this.model.appendRow(); > + this.lastPath.next(); > + numInstructions++; > + } > + > + refreshList(); > + fromBox.setText("0x" + Long.toHexString((long)lastKnownFrom)); > + fromSpin.setValue(lastKnownFrom); > + } > > /**************************************************************************** > * Save and Load > Index: memory/MemoryWindow.java > =================================================================== > RCS file: /cvs/frysk/frysk-gui/frysk/gui/memory/MemoryWindow.java,v > retrieving revision 1.46 > diff -u -r1.46 MemoryWindow.java > --- memory/MemoryWindow.java 7 Sep 2007 03:18:50 -0000 1.46 > +++ memory/MemoryWindow.java 12 Sep 2007 07:43:29 -0000 > @@ -42,6 +42,7 @@ > package frysk.gui.memory; > > import java.util.prefs.Preferences; > +import java.util.LinkedList; > import java.util.List; > import java.util.Iterator; > import java.util.Observable; > @@ -78,6 +79,7 @@ > import org.gnu.gtk.event.SpinEvent; > import org.gnu.gtk.event.SpinListener; > > +import frysk.dwfl.DwflCache; > import frysk.gui.common.IconManager; > import frysk.gui.prefs.PreferenceManager; > import frysk.gui.monitor.GuiObject; > @@ -87,8 +89,13 @@ > import frysk.proc.Proc; > import frysk.proc.Task; > import frysk.stepping.TaskStepEngine; > +import frysk.symtab.Symbol; > +import frysk.symtab.SymbolFactory; > import frysk.proc.MemoryMap; > > +import lib.dwfl.Dwfl; > +import lib.dwfl.DwflModule; > +import lib.dwfl.SymbolBuilder; > import lib.opcodes.Disassembler; > import lib.opcodes.Instruction; > > @@ -511,28 +518,41 @@ > return; > > String str = fromBox.getText(); > - str = str.substring(2); > - try > + if (str.startsWith("0x")) > { > - double d = (double) Long.parseLong(str, 16); > - if (!addressAccessible((long)d)) > - fromBox.setText("0x" + Long.toHexString((long) > lastKnownFrom)); > - else > - { > - if (d > lastKnownTo) > + str = str.substring(2); > + try > + { > + double d = (double) Long.parseLong(str, > 16); > + if (!addressAccessible((long)d)) > + fromBox.setText("0x" + Long.toHexString((long) > lastKnownFrom)); > + else > { > - if (lastKnownTo == lastKnownFrom) > - handleFromSpin(lastKnownTo); > + if (d > lastKnownTo) > + { > + if (lastKnownTo == lastKnownFrom) > + handleFromSpin(lastKnownTo); > + else > + fromSpin.setValue(lastKnownTo); > + } > else > - fromSpin.setValue(lastKnownTo); > > + fromSpin.setValue(d); > } > - else > - fromSpin.setValue(d); > - } > + } > + catch (NumberFormatException nfe) > + { > + fromBox.setText("0x" + Long.toHexString((long) > lastKnownFrom)); > + } > } > - catch (NumberFormatException nfe) > - { > - fromBox.setText("0x" + Long.toHexString((long) > lastKnownFrom)); > + else > + { > + try > + { > + handleSymbol(str); > + } > + catch (RuntimeException e){ > + fromBox.setText("0x" + Long.toHexString((long) > lastKnownFrom)); > + } > } > } > } > @@ -548,23 +568,41 @@ > return; > > String str = toBox.getText(); > - str = str.substring(2); > - try > + if (str.startsWith("0x")) > { > - double d = (double) Long.parseLong(str, 16); > - if (d < lastKnownFrom) > - { > - if (lastKnownFrom == lastKnownTo) > - handleToSpin(lastKnownFrom); > - else > - toSpin.setValue(lastKnownFrom); > - } > - else > - toSpin.setValue(d); > + str = str.substring(2); > + try > + { > + double d = (double) Long.parseLong(str, > 16); > + if (!(addressAccessible((long)d))) > + toBox.setText("0x" + Long.toHexString((long) > lastKnownTo)); > + else > + { > + if (d < lastKnownFrom) > + { > + if (lastKnownFrom == lastKnownTo) > + handleToSpin(lastKnownFrom); > + else > + toSpin.setValue(lastKnownFrom); > + } > + else > + toSpin.setValue(d); > + } > + } > + catch (NumberFormatException nfe) > + { > + toBox.setText("0x" + Long.toHexString((long) > lastKnownTo)); > + } > } > - catch (NumberFormatException nfe) > - { > - toBox.setText("0x" + Long.toHexString((long) > lastKnownTo)); > + else > + { > + try > + { > + handleSymbol(str); > + } > + catch (RuntimeException e){ > + toBox.setText("0x" + Long.toHexString((long) > lastKnownTo)); > + } > } > } > } > @@ -573,6 +611,32 @@ > } > > /** > + * Get the address list from symbol name; > + * @param name > + * @return address list > + */ > + private LinkedList addressesForSymbol(String name) { > + Dwfl dwfl = DwflCache.getDwfl(this.myTask); > + DwflModule[] modules = dwfl.getModules(); > + final LinkedList addrs = new LinkedList(); > + SymbolBuilder builder = new SymbolBuilder() { > + public void symbol(String name, long value, long size, > + int type, int bind, int visibility) { > + addrs.add(new Long(value)); > + } > + }; > + for (int i = 0; i < modules.length; i++) > + { > + DwflModule module = modules[i]; > + module.getSymbolByName(name, builder); > + } > + if (addrs.size() == 0) > + throw new RuntimeException("Couldn't find symbol " + > name); > + else > + return addrs; > + } > + > + /** > * return a boolean indicating whether or not this address > is accessible. > * > * @return whether or not this address is accessible > @@ -612,6 +676,7 @@ > this.refreshLock = false; > } > > + > /***************************************************************************** > * Calculation, memory reading, and information display > methods > ****************************************************************************/ > @@ -1011,6 +1076,47 @@ > this.lastKnownTo = val; > refreshList(); > } > + > + /** > + * When the box is inputed a symbol, update the displayed > information to the symbol. > + * @param symbolName > + */ > + private synchronized void handleSymbol(String symbolName) > + { > + LinkedList addressList = addressesForSymbol(symbolName); > + long startAddress = ((Long)addressList.getFirst()).longValue(); > + Symbol symbol = SymbolFactory.getSymbol(this.myTask, > startAddress); > + long endAddress = symbol.getAddress() + symbol.getSize(); > + long size = endAddress - startAddress + 1; > + long modelSize = (long)lastKnownTo - (long)lastKnownFrom > + 1; > + TreeIter iter = this.model.getFirstIter(); > + while (size < modelSize) > + { > + this.model.removeRow(iter); > + this.lastPath.previous(); > + modelSize--; > + } > + while(size > modelSize) > + { > + this.model.appendRow(); > + this.lastPath.next(); > + modelSize++; > + } > + this.lastKnownFrom = (double)startAddress; > + this.lastKnownTo = (double)endAddress; > + iter = this.model.getFirstIter(); > + this.lastPath = iter.getPath(); > + for(long i= startAddress; i < endAddress+1; i++) > + { > + rowAppend(i, iter); > + iter = iter.getNextIter(); > + } > + refreshList(); > + fromBox.setText("0x" + Long.toHexString((long)lastKnownFrom)); > + fromSpin.setValue(lastKnownFrom); > + toBox.setText("0x" + Long.toHexString((long)lastKnownTo)); > + toSpin.setValue(lastKnownTo); > + } > > /**************************************************************************** > * Save and Load > From kris.van.hees@oracle.com Thu Sep 13 12:34:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Thu, 13 Sep 2007 12:34:00 -0000 Subject: Patch for TearDownProcess In-Reply-To: <46E15274.5020400@redhat.com> References: <20070907022100.GK22263@oracle.com> <46E15274.5020400@redhat.com> Message-ID: <20070913123203.GD21435@oracle.com> In view of the quote below, and history over the past couple of months, I'd like to pose an important question to the overall developer community behind Frysk: Should we strive to have a consistent, dependable testsuite? The reason to ask is that on one hand, it seems some people prefer to look at tests as individual units, regardless of their side-effects on later tests in the testsuite (see the past discussions about the file descriptor leak testing and its effects on the testsuite), whereas others prefer to see the testsuite as a collection of tests that needs to be capable of producing dependable results regardless of the outcome of one or more individual tests. Right now it seems that not everyone is even on a specific side of the issue, preferring one behaviour for some test cases, and the other for other test cases. The end result is that the Frysk testsuite is not producing results that can be considered a valid indicator in terms of correctness. In addition, just yesterday we encountered a case where some build-time testing is conditional, causing a commit to go through (tested on F7 prior to commit) that broke the build on other platforms (FC6) because on the latter platform the test was enabled. That kind of thing obviously gives developers a wrong impression on whether their patch is going to be break builds or not. Today I am seeing the following (first time I say this was July 3rd, and it was reported in bugzilla): | Running testDataFuncPeekBytes(frysk.sys.TestPtrace) ...PASS | Running testDataFuncPeekBytes(frysk.sys.TestPtrace) ...ERROR | close: Bad file descriptor (fd 0) | Running testLengthUnderBound(frysk.sys.TestPtrace) ...PASS | Running testLengthUnderBound(frysk.sys.TestPtrace) ...ERROR | close: Bad file descriptor (fd 0) | Running testOffsetUnderBound(frysk.sys.TestPtrace) ...PASS | Running testOffsetUnderBound(frysk.sys.TestPtrace) ...ERROR | close: Bad file descriptor (fd 0) | Running testLengthOverBound(frysk.sys.TestPtrace) ...PASS | Running testLengthOverBound(frysk.sys.TestPtrace) ...ERROR | close: Bad file descriptor (fd 0) | Running testOffsetOverBound(frysk.sys.TestPtrace) ...PASS | Running testOffsetOverBound(frysk.sys.TestPtrace) ...PASS | Running testLengthOnBound(frysk.sys.TestPtrace) ...ERROR | close: Bad file descriptor (fd 0) | Running testOffsetOnBound(frysk.sys.TestPtrace) ...PASS | Running testOffsetOnBound(frysk.sys.TestPtrace) ...PASS While it can be argued that a test reporting its result twice is hardly an issue, I would think that a single test reporting both a PASS *and* an ERROR result would be more reason for concern... In all, most development methodologies put a lot of value in testing. It is also my experience that even without a formal methodology, testing tends to be considered rather important. I do not believe that the Frysk testsuite can be taken seriously as long as we cannot have a consistent policy in terms of test quality. Either test we allow failing tests to potentially corrupt the validity of following tests, or we prohibit failing tests from corrupting the validity of following tests. Having it one way in some cases, and the other way in some other cases simply leads to not being able to trust the results of the testsuite at all. Cheers, Kris On Fri, Sep 07, 2007 at 09:30:28AM -0400, Andrew Cagney wrote: > Given the choices between a potential test-suite hang, and tear-down > leaving waitpid events around, the decision was made in favor of the > latter. That decision hasn't changed. Having the test run hang, is a > lesser evil then the test-suite continuing but producing bogus results.. > I restored the old behavior; and then added a timeout. It currently logs a > message, I suspect it should abandon the test run, since the problem state > hasn't gone away. > > Andrew > From pearly.zhao@oracle.com Wed Sep 19 01:19:00 2007 From: pearly.zhao@oracle.com (Zhao Shujing) Date: Wed, 19 Sep 2007 01:19:00 -0000 Subject: [patch] Accept symbolic addresses in spin button, bug 4673. In-Reply-To: <17474866.1189604007745.JavaMail.oracle@acsmt303.oracle.com> References: <1189584690.4843.23.camel@linux-pzhao.site> <17474866.1189604007745.JavaMail.oracle@acsmt303.oracle.com> Message-ID: <1190165163.24118.3.camel@linux-pzhao.site> Hi, This is a new patch. It adds getSymbol(task, name) method to SymbolFactory. The BreakpointManager and FunctionBreakpoint are changed to use this method instead of using the one defined by themselves. Any suggestions are welcomed. Pearly On Wed, 2007-09-12 at 08:33 -0500, PEARLY.ZHAO@oracle.com wrote: > Actually, retrieving symbol addresses in the classes implementing the disssembly and memory windows is a wrong way to implement this functionality. Maybe it should be designed at core. The classes handling the windows merely use it to obtain the information. > > Pearly > > > Hi, > > > > This patch can make the disassembly/memory window accept symbol > > name in > > spin Button. > > > > Here is what it does: > > - When input a available symbol name at fromBox, the window > > would > > display the disassembly/memory of this symbol. The fromBox/fromSpin > > would be set the start address of this symbol and the toBox/toSpin > > would > > be set the end address of this symbol. > > - When input a available symbol name at toBox, it would do as > > same as > > when input at fromBox. > > - When input a unavailable symbol name, the fromBox/fromSpin > > or > > toBox/toSpin would be reset to the lastKnownFrom or lastKnownTo. > > > > Any suggestions are welcomed. > > > > Pearly Zhao > > > > --------Index: disassembler/DisassemblyWindow.java > > =================================================================== > > RCS file: /cvs/frysk/frysk-gui/frysk/gui/disassembler/DisassemblyWindow.java,v > > retrieving revision 1.31 > > diff -u -r1.31 DisassemblyWindow.java > > --- disassembler/DisassemblyWindow.java 7 Sep 2007 03:18:50 > > -0000 1.31 > > +++ disassembler/DisassemblyWindow.java 12 Sep 2007 07:43:28 > > -0000 > > @@ -42,6 +42,7 @@ > > package frysk.gui.disassembler; > > > > import java.util.prefs.Preferences; > > +import java.util.LinkedList; > > import java.util.List; > > import java.util.Iterator; > > import java.util.ListIterator; > > @@ -74,6 +75,7 @@ > > import org.gnu.gtk.event.SpinEvent; > > import org.gnu.gtk.event.SpinListener; > > > > +import frysk.dwfl.DwflCache; > > import frysk.gui.common.IconManager; > > import frysk.gui.prefs.PreferenceManager; > > import frysk.gui.monitor.Saveable; > > @@ -81,7 +83,12 @@ > > import frysk.proc.Task; > > import frysk.stepping.TaskStepEngine; > > import frysk.proc.MemoryMap; > > +import frysk.symtab.Symbol; > > +import frysk.symtab.SymbolFactory; > > > > +import lib.dwfl.Dwfl; > > +import lib.dwfl.DwflModule; > > +import lib.dwfl.SymbolBuilder; > > import lib.opcodes.Disassembler; > > import lib.opcodes.Instruction; > > > > @@ -379,28 +386,42 @@ > > return; > > > > String str = fromBox.getText(); > > - str = str.substring(2); > > - try > > + > > + if (str.startsWith("0x")) > > { > > - double d = (double) Long.parseLong(str, 16); > > - if (!addressAccessible((long)d)) > > - fromBox.setText("0x" + Long.toHexString((long) > > lastKnownFrom)); > > - else > > - { > > - if (d > lastKnownTo) > > + str = str.substring(2); > > + try > > + { > > + double d = (double) Long.parseLong(str, > > 16); > > + if (!addressAccessible((long)d)) > > + fromBox.setText("0x" + Long.toHexString((long) > > lastKnownFrom)); > > + else > > { > > - if (lastKnownTo == lastKnownFrom) > > - handleFromSpin(lastKnownTo); > > + if (d > lastKnownTo) > > + { > > + if (lastKnownTo == lastKnownFrom) > > + handleFromSpin(lastKnownTo); > > + else > > + fromSpin.setValue(lastKnownTo); > > + } > > else > > - fromSpin.setValue(lastKnownTo); > > + fromSpin.setValue(d); > > } > > - else > > - fromSpin.setValue(d); > > - } > > + } > > + catch (NumberFormatException nfe) > > + { > > + fromBox.setText("0x" + Long.toHexString((long) > > lastKnownFrom)); > > + } > > } > > - catch (NumberFormatException nfe) > > - { > > - fromBox.setText("0x" + Long.toHexString((long) > > lastKnownFrom)); > > + else > > + { > > + try > > + { > > + handleSymbol(str); > > + } > > + catch (RuntimeException e){ > > + fromBox.setText("0x" + Long.toHexString((long) > > lastKnownFrom)); > > + } > > } > > } > > } > > @@ -416,28 +437,41 @@ > > return; > > > > String str = toBox.getText(); > > - str = str.substring(2); > > - try > > + if (str.startsWith("0x")) > > { > > - double d = (double) Long.parseLong(str, 16); > > - if (!(addressAccessible((long)d))) > > - toBox.setText("0x" + Long.toHexString((long) > > lastKnownTo)); > > - else > > - { > > - if (d < lastKnownFrom) > > + str = str.substring(2); > > + try > > + { > > + double d = (double) Long.parseLong(str, > > 16); > > + if (!(addressAccessible((long)d))) > > + toBox.setText("0x" + Long.toHexString((long) > > lastKnownTo)); > > + else > > { > > - if (lastKnownFrom == lastKnownTo) > > - handleToSpin(lastKnownFrom); > > + if (d < lastKnownFrom) > > + { > > + if (lastKnownFrom == lastKnownTo) > > + handleToSpin(lastKnownFrom); > > + else > > + toSpin.setValue(lastKnownFrom); > > + } > > else > > - toSpin.setValue(lastKnownFrom); > > + toSpin.setValue(d); > > } > > - else > > - toSpin.setValue(d); > > - } > > + } > > + catch (NumberFormatException nfe) > > + { > > + toBox.setText("0x" + Long.toHexString((long) > > lastKnownTo)); > > + } > > } > > - catch (NumberFormatException nfe) > > - { > > - toBox.setText("0x" + Long.toHexString((long) > > lastKnownTo)); > > + else > > + { > > + try > > + { > > + handleSymbol(str); > > + } > > + catch (RuntimeException e){ > > + toBox.setText("0x" + Long.toHexString((long) > > lastKnownTo)); > > + } > > } > > } > > } > > @@ -539,6 +573,32 @@ > > } > > this.refreshList(); > > } > > + > > + /** > > + * Get the address list from symbol name; > > + * @param name > > + * @return address list > > + */ > > + private LinkedList addressesForSymbol(String name) { > > + Dwfl dwfl = DwflCache.getDwfl(this.myTask); > > + DwflModule[] modules = dwfl.getModules(); > > + final LinkedList addrs = new LinkedList(); > > + SymbolBuilder builder = new SymbolBuilder() { > > + public void symbol(String name, long value, long size, > > + int type, int bind, int visibility) { > > + addrs.add(new Long(value)); > > + } > > + }; > > + for (int i = 0; i < modules.length; i++) > > + { > > + DwflModule module = modules[i]; > > + module.getSymbolByName(name, builder); > > + } > > + if (addrs.size() == 0) > > + throw new RuntimeException("Couldn't find symbol " + > > name); > > + else > > + return addrs; > > + } > > /** > > * return a boolean indicating whether or not this address > > is accessible. > > * > > @@ -640,16 +700,17 @@ > > * By default append rows to the end. > > * > > * @param i The address to be displayed > > + * @param numIns The Instructions that maybe be added > > * @param iter The TreeIter representing the row to be > > added. > > */ > > - public synchronized void rowAppend (long i, TreeIter iter) > > + public synchronized void rowAppend (long i, int numIns, > > TreeIter iter) > > { > > // if (iter == null) > > // iter = model.appendRow(); > > > > List instructionsList > > = diss.disassembleInstructions((long) this.lastKnownTo, > > - numInstructions); > > + numInstructions+numIns); > > Iterator li = instructionsList.listIterator(0); > > Instruction ins = (Instruction) li.next(); > > > > @@ -661,8 +722,10 @@ > > this.lastPath.next(); > > if (ins != null) > > { > > - if (li.hasNext()) > > + if (li.hasNext()){ > > ins = (Instruction) li.next(); > > + this.numInstructions++; > > + } > > else > > { > > this.toSpin.setValue((double) ins.address); > > @@ -858,10 +921,11 @@ > > > > if (val > this.lastKnownTo) > > { > > - for (long i = (long) lastKnownTo + 1; i < val + 1; > > i++) > > - ++this.numInstructions; > > + int numIns = 0; > > + for (long i = (long) lastKnownTo + 1; i < val + 1; i++) > > + ++numIns; > > > > - rowAppend((long) val, null); > > + rowAppend((long) val, numIns, null); > > > > return; > > } > > @@ -895,6 +959,48 @@ > > refreshList(); > > } > > } > > + > > + /** > > + * When the box is inputed a symbol, update the displayed > > information to the symbol. > > + * @param symbolName > > + */ > > + private synchronized void handleSymbol(String symbolName) > > + { > > + LinkedList addressList = addressesForSymbol(symbolName); > > + long startAddress = ((Long)addressList.getFirst()).longValue(); > > + Symbol symbol = SymbolFactory.getSymbol(this.myTask, > > startAddress); > > + long endAddress = symbol.getAddress() + symbol.getSize(); > > + > > + List instructionsList > > + = diss.disassembleInstructionsStartEnd((long)startAddress, > > (long)endAddress); > > + Iterator li = instructionsList.listIterator(0); > > + int insnum = 1; > > + Instruction ins = (Instruction)li.next(); > > + this.lastKnownFrom = (double)ins.address; > > + while (li.hasNext()){ > > + ins = (Instruction)li.next(); > > + insnum++; > > + } > > + this.lastKnownTo = (double)ins.address; > > + > > + TreeIter iter = this.model.getFirstIter(); > > + while (insnum < numInstructions) > > + { > > + this.model.removeRow(iter); > > + this.lastPath.previous(); > > + numInstructions--; > > + } > > + while(insnum > numInstructions) > > + { > > + this.model.appendRow(); > > + this.lastPath.next(); > > + numInstructions++; > > + } > > + > > + refreshList(); > > + fromBox.setText("0x" + Long.toHexString((long)lastKnownFrom)); > > + fromSpin.setValue(lastKnownFrom); > > + } > > > > /**************************************************************************** > > * Save and Load > > Index: memory/MemoryWindow.java > > =================================================================== > > RCS file: /cvs/frysk/frysk-gui/frysk/gui/memory/MemoryWindow.java,v > > retrieving revision 1.46 > > diff -u -r1.46 MemoryWindow.java > > --- memory/MemoryWindow.java 7 Sep 2007 03:18:50 -0000 1.46 > > +++ memory/MemoryWindow.java 12 Sep 2007 07:43:29 -0000 > > @@ -42,6 +42,7 @@ > > package frysk.gui.memory; > > > > import java.util.prefs.Preferences; > > +import java.util.LinkedList; > > import java.util.List; > > import java.util.Iterator; > > import java.util.Observable; > > @@ -78,6 +79,7 @@ > > import org.gnu.gtk.event.SpinEvent; > > import org.gnu.gtk.event.SpinListener; > > > > +import frysk.dwfl.DwflCache; > > import frysk.gui.common.IconManager; > > import frysk.gui.prefs.PreferenceManager; > > import frysk.gui.monitor.GuiObject; > > @@ -87,8 +89,13 @@ > > import frysk.proc.Proc; > > import frysk.proc.Task; > > import frysk.stepping.TaskStepEngine; > > +import frysk.symtab.Symbol; > > +import frysk.symtab.SymbolFactory; > > import frysk.proc.MemoryMap; > > > > +import lib.dwfl.Dwfl; > > +import lib.dwfl.DwflModule; > > +import lib.dwfl.SymbolBuilder; > > import lib.opcodes.Disassembler; > > import lib.opcodes.Instruction; > > > > @@ -511,28 +518,41 @@ > > return; > > > > String str = fromBox.getText(); > > - str = str.substring(2); > > - try > > + if (str.startsWith("0x")) > > { > > - double d = (double) Long.parseLong(str, 16); > > - if (!addressAccessible((long)d)) > > - fromBox.setText("0x" + Long.toHexString((long) > > lastKnownFrom)); > > - else > > - { > > - if (d > lastKnownTo) > > + str = str.substring(2); > > + try > > + { > > + double d = (double) Long.parseLong(str, > > 16); > > + if (!addressAccessible((long)d)) > > + fromBox.setText("0x" + Long.toHexString((long) > > lastKnownFrom)); > > + else > > { > > - if (lastKnownTo == lastKnownFrom) > > - handleFromSpin(lastKnownTo); > > + if (d > lastKnownTo) > > + { > > + if (lastKnownTo == lastKnownFrom) > > + handleFromSpin(lastKnownTo); > > + else > > + fromSpin.setValue(lastKnownTo); > > + } > > else > > - fromSpin.setValue(lastKnownTo); > > > > + fromSpin.setValue(d); > > } > > - else > > - fromSpin.setValue(d); > > - } > > + } > > + catch (NumberFormatException nfe) > > + { > > + fromBox.setText("0x" + Long.toHexString((long) > > lastKnownFrom)); > > + } > > } > > - catch (NumberFormatException nfe) > > - { > > - fromBox.setText("0x" + Long.toHexString((long) > > lastKnownFrom)); > > + else > > + { > > + try > > + { > > + handleSymbol(str); > > + } > > + catch (RuntimeException e){ > > + fromBox.setText("0x" + Long.toHexString((long) > > lastKnownFrom)); > > + } > > } > > } > > } > > @@ -548,23 +568,41 @@ > > return; > > > > String str = toBox.getText(); > > - str = str.substring(2); > > - try > > + if (str.startsWith("0x")) > > { > > - double d = (double) Long.parseLong(str, 16); > > - if (d < lastKnownFrom) > > - { > > - if (lastKnownFrom == lastKnownTo) > > - handleToSpin(lastKnownFrom); > > - else > > - toSpin.setValue(lastKnownFrom); > > - } > > - else > > - toSpin.setValue(d); > > + str = str.substring(2); > > + try > > + { > > + double d = (double) Long.parseLong(str, > > 16); > > + if (!(addressAccessible((long)d))) > > + toBox.setText("0x" + Long.toHexString((long) > > lastKnownTo)); > > + else > > + { > > + if (d < lastKnownFrom) > > + { > > + if (lastKnownFrom == lastKnownTo) > > + handleToSpin(lastKnownFrom); > > + else > > + toSpin.setValue(lastKnownFrom); > > + } > > + else > > + toSpin.setValue(d); > > + } > > + } > > + catch (NumberFormatException nfe) > > + { > > + toBox.setText("0x" + Long.toHexString((long) > > lastKnownTo)); > > + } > > } > > - catch (NumberFormatException nfe) > > - { > > - toBox.setText("0x" + Long.toHexString((long) > > lastKnownTo)); > > + else > > + { > > + try > > + { > > + handleSymbol(str); > > + } > > + catch (RuntimeException e){ > > + toBox.setText("0x" + Long.toHexString((long) > > lastKnownTo)); > > + } > > } > > } > > } > > @@ -573,6 +611,32 @@ > > } > > > > /** > > + * Get the address list from symbol name; > > + * @param name > > + * @return address list > > + */ > > + private LinkedList addressesForSymbol(String name) { > > + Dwfl dwfl = DwflCache.getDwfl(this.myTask); > > + DwflModule[] modules = dwfl.getModules(); > > + final LinkedList addrs = new LinkedList(); > > + SymbolBuilder builder = new SymbolBuilder() { > > + public void symbol(String name, long value, long size, > > + int type, int bind, int visibility) { > > + addrs.add(new Long(value)); > > + } > > + }; > > + for (int i = 0; i < modules.length; i++) > > + { > > + DwflModule module = modules[i]; > > + module.getSymbolByName(name, builder); > > + } > > + if (addrs.size() == 0) > > + throw new RuntimeException("Couldn't find symbol " + > > name); > > + else > > + return addrs; > > + } > > + > > + /** > > * return a boolean indicating whether or not this address > > is accessible. > > * > > * @return whether or not this address is accessible > > @@ -612,6 +676,7 @@ > > this.refreshLock = false; > > } > > > > + > > /***************************************************************************** > > * Calculation, memory reading, and information display > > methods > > ****************************************************************************/ > > @@ -1011,6 +1076,47 @@ > > this.lastKnownTo = val; > > refreshList(); > > } > > + > > + /** > > + * When the box is inputed a symbol, update the displayed > > information to the symbol. > > + * @param symbolName > > + */ > > + private synchronized void handleSymbol(String symbolName) > > + { > > + LinkedList addressList = addressesForSymbol(symbolName); > > + long startAddress = ((Long)addressList.getFirst()).longValue(); > > + Symbol symbol = SymbolFactory.getSymbol(this.myTask, > > startAddress); > > + long endAddress = symbol.getAddress() + symbol.getSize(); > > + long size = endAddress - startAddress + 1; > > + long modelSize = (long)lastKnownTo - (long)lastKnownFrom > > + 1; > > + TreeIter iter = this.model.getFirstIter(); > > + while (size < modelSize) > > + { > > + this.model.removeRow(iter); > > + this.lastPath.previous(); > > + modelSize--; > > + } > > + while(size > modelSize) > > + { > > + this.model.appendRow(); > > + this.lastPath.next(); > > + modelSize++; > > + } > > + this.lastKnownFrom = (double)startAddress; > > + this.lastKnownTo = (double)endAddress; > > + iter = this.model.getFirstIter(); > > + this.lastPath = iter.getPath(); > > + for(long i= startAddress; i < endAddress+1; i++) > > + { > > + rowAppend(i, iter); > > + iter = iter.getNextIter(); > > + } > > + refreshList(); > > + fromBox.setText("0x" + Long.toHexString((long)lastKnownFrom)); > > + fromSpin.setValue(lastKnownFrom); > > + toBox.setText("0x" + Long.toHexString((long)lastKnownTo)); > > + toSpin.setValue(lastKnownTo); > > + } > > > > /**************************************************************************** > > * Save and Load > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: getSymbol.patch Type: text/x-patch Size: 19600 bytes Desc: URL: From elena.zannoni@oracle.com Wed Sep 19 14:32:00 2007 From: elena.zannoni@oracle.com (Elena Zannoni) Date: Wed, 19 Sep 2007 14:32:00 -0000 Subject: minutes of 2007-09-19 meeting Message-ID: <46F13329.6000406@oracle.com> Frysk Meeting 2007-09-19 Sami, Mark, Stan, Phil, Elena, Rick, Tim. Questions about shared library loading: solib debugging flags: were added in gdb long time ago. Look at this gdb branch: ezannoni_pie-20040323-branch Roundtable --------------- Mark: libunwind stuff: done merge of upstream libunwind. This is before the ppc32 work in libunwind is finished. ppc64 stuff has been merged into the frysk libunwind. There are 30 local patches some of which should be upstream. Signal unwinding is one of these patches. After that's done will add the debugframe stuff. libunwind doesn't do debugframe support not wanted upstream in libunwind cross architecture builds are needed by frysk, where we link the 32 and 64 bit libunwind to do 32 bit unwinding together with 64 bit. Upstream doesn't do that. A local copy of libunwind is needed for this reason. Pearly: for now working on disassembler and memory window bugs. We'll need to figure out the next task in a few weeks. Kris: working on labrat improvements this week. Phil: background reading on HW watchpoints. How the kernel sets and clears the hw debug registers is a complicated matter, and varies btw arches. Sami: C++ scoping rules in frysk: added to frame object a function to search according to scoping rules, and working on writing a search engine for C++. Tim: looking at bugs from last meeting when breakpoints are being hit. cli needs to be notified in more circumstances than it is now. Problems with multi threaded cases: stepping engine observer, function gets called when step completed. in MT situations: currently only report when all the threads have finished their steps, but if you are to step into a function, one thread could end up blocking on a ptrhead blocking call and it will never finish its step, the stepping engine will not report back that the step has finished, because it has to wait for all the threads. Should instead be notified wherver any thread finishes a step, w/o waiting for all of them. Or something of the sort. Still trying to figure out what the right thing to do is. Importing history into GIT. Did a prototype of that. Was ablt to go back at any point and rebuild the project at that point. Stan: split off the type evaluation from the exp evaluation. Type and value are evaluated in different places now. No more monolythic routine, it is now done in the class that correspoinds to the type. Short int eval is done in the short int class, and so on. This enables the expression tree generated by antlr to be annotated with types for each node of the tree. Now each piece can have a type on it. Makefile assumed that there was one antlr file, changed that to allow multiple antrl files. Rick: Some vacation. But working with Phil on corefiles, translate that to the executable file, fhpd "load" command. Trying testcase, and refine that. Hopefully will be done sometimes this week. Able to look at memory location wthin an executbale. Teresa: OP_Piece: it's working for registers and memory as far as we know. Not turned on yet. Sami reports that testing with that enabled results in better test results. From tthomas@redhat.com Wed Sep 19 15:03:00 2007 From: tthomas@redhat.com (Teresa Thomas) Date: Wed, 19 Sep 2007 15:03:00 -0000 Subject: minutes of 2007-09-19 meeting In-Reply-To: <46F13329.6000406@oracle.com> References: <46F13329.6000406@oracle.com> Message-ID: <46F13A4D.5090408@redhat.com> > Teresa: > OP_Piece: it's working for registers and memory as far as we know. Not > turned on yet. Sami reports that testing with that enabled results in > better test results. The location code correctly decodes the location of the values, whether in memory, register or with a memory split. Facing two problems with manipulating variable values, (1) Getting variable values does not return expected value in 32 bit machines though it does this for x86_64. Examining the memory of the task in a 32-bit machine shows that it contains the LSB of the value at the decoded location, but the the bytes that follow are random. (2) Frame's setReg does not change the value of the register. So setting values is possible in memory but not regs. Its probably not a good idea to enable the new location code atleast till (1) is fixed. From pearly.zhao@oracle.com Fri Sep 21 08:19:00 2007 From: pearly.zhao@oracle.com (Zhao Shujing) Date: Fri, 21 Sep 2007 08:19:00 -0000 Subject: [patch] Memory Window: Change the location increment by eight. Fix bug 4674 Message-ID: <1190363168.3820.7.camel@linux-pzhao.site> Hi After investigate gdb, gtk/insight and other debugger of Linux, the location increment of memory window is change to eight, that is, it display 64bit every row. Any suggestions are welcomed. Pearly -------------- next part -------------- A non-text attachment was scrubbed... Name: 4674.patch Type: text/x-patch Size: 13534 bytes Desc: URL: From cagney@redhat.com Fri Sep 21 21:53:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 21 Sep 2007 21:53:00 -0000 Subject: [patch] Accept symbolic addresses in spin button, bug 4673. In-Reply-To: <1190165163.24118.3.camel@linux-pzhao.site> References: <1189584690.4843.23.camel@linux-pzhao.site> <17474866.1189604007745.JavaMail.oracle@acsmt303.oracle.com> <1190165163.24118.3.camel@linux-pzhao.site> Message-ID: <46F43D52.1040602@redhat.com> Pearly, > Hi, > This is a new patch. It adds getSymbol(task, name) method to > SymbolFactory. The BreakpointManager and FunctionBreakpoint are changed > to use this method instead of using the one defined by themselves. > > Any suggestions are welcomed. > > Pearly > On Wed, 2007-09-12 at 08:33 -0500, PEARLY.ZHAO@oracle.com wrote: > > > Actually, retrieving symbol addresses in the classes implementing the disssembly and memory windows is a wrong way to implement this functionality. Maybe it should be designed at core. The classes handling the windows merely use it to obtain the information. Yes, agreed; but rather than assuming the string is a symbol, would it be more robust to evaluate the string as an expression? Thus allowing arbitrary expressions and symbols vis: foo+10 and not limiting things to symbols (See DisassembleCommand for how it evaluates its parameters). BTW, + + /** + * Get address list by symbol name + * @param task + * @param name + * @return address list + */ + public static LinkedList getSymbol(Task task, String name) { + Dwfl dwfl = DwflCache.getDwfl(task); + DwflModule[] modules = dwfl.getModules(); + final LinkedList addrs = new LinkedList(); is for searching out duplicate symbols so that a breakpoint can be inserted at all locations; since here only a single location (based on the current pc and elf/c scope rules) is needed, using it and discarding all but the first address isn't correct. You can assume that the expression evaluator will get this right, and if it doesn't we've an expression evaluation bug. In refactoring getSymbol to frysk.symtab.SymbolFactory did you take the opportunity to add a test case? Andrew From tthomas@redhat.com Tue Sep 25 14:50:00 2007 From: tthomas@redhat.com (Teresa Thomas) Date: Tue, 25 Sep 2007 14:50:00 -0000 Subject: Location Expression enabled Message-ID: <46F92027.1090606@redhat.com> The new Location Expression code has been enabled in the main repo. Currently, we can switch between the old and the new code by setting the static variable /useLocationExpressionFIXME/ in /Variable.java/. So if you find anything broken and want to confirm if it is due to the switch, change /useLocationExpressionFIXME/ to false to revert back to the old Location stuff. Ping me if anything looks nasty! Cheers, Teresa From cagney@redhat.com Tue Sep 25 17:58:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 25 Sep 2007 17:58:00 -0000 Subject: no meeting 2007-09-26 Message-ID: <46F94BBB.5040703@redhat.com> just fyi, no one from Red Hat can make it (clash). From scox@redhat.com Wed Sep 26 02:44:00 2007 From: scox@redhat.com (Stan Cox) Date: Wed, 26 Sep 2007 02:44:00 -0000 Subject: antlr expression tree annotator Message-ID: <1190774413.26510.108.camel@multics.rdu.redhat.com> An antlr infrastructure for walking and tagging the expression tree with type information was committed. At the moment only symbol nodes are tagged and there are currently no consumers of the information. When I get a bit more time I'll finish polishing up a 'what' request that uses this and also add type info on the operator nodes. files in frysk-core/frysk/expr: CExpr.g antlr lexer and parser grammar CExprAnnotator.g antlr type annotator CExprEvaluator.g antlr expression evaluator ExprAST.java extension of antlr's abstract syntax tree ExprSymTab.java interface to frysk-core/debuginfo (this interface has possibly outlived its usefulness as the testing tools that also used it are no longer needed and are removed) From tthomas@redhat.com Wed Sep 26 20:43:00 2007 From: tthomas@redhat.com (Teresa Thomas) Date: Wed, 26 Sep 2007 20:43:00 -0000 Subject: New fhpd commands: ptype & plocation Message-ID: <46FAC452.4010301@redhat.com> Two new commands have been added to fhpd: 1) ptype : prints the type of variable/expression 2) plocation : prints the location of variable, displaying any memory split if present. Example (attached to hpd-c): ============================ (fhpd) ptype arr_1 [0.0] long int [32] (fhpd) plocation static_int [0.0] Address 0x8049e34 - 4 byte(s) (fhpd) plocation int_21 [0.0] Register eax - 4 byte(s) ============================ For multiple pieces the output of plocation will look like: Piece 0: < location details > Piece 1: < location details > etc Any suggestions on improving the output format? Cheers, Teresa From pmuldoon@redhat.com Thu Sep 27 06:49:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 27 Sep 2007 06:49:00 -0000 Subject: New fhpd commands: ptype & plocation In-Reply-To: <46FAC452.4010301@redhat.com> References: <46FAC452.4010301@redhat.com> Message-ID: <46FB527F.2070809@redhat.com> Teresa Thomas wrote: > Two new commands have been added to fhpd: > 1) ptype : prints the type of variable/expression > 2) plocation : prints the location of variable, > displaying any memory split if present. > Nice bit of "just in time" here as I will soon be using this stuff for watchpoints (ie translating a variable to a location, or locations). Apart from the output code, and parsing code in fhpd, is the "get the location" code placed in a utility class somewhere? Can you give a programming example of given variable foo, how to get a location or locations in memory of where it resides? Regards Phil From tthomas@redhat.com Thu Sep 27 14:14:00 2007 From: tthomas@redhat.com (Teresa Thomas) Date: Thu, 27 Sep 2007 14:14:00 -0000 Subject: New fhpd commands: ptype & plocation In-Reply-To: <46FB527F.2070809@redhat.com> References: <46FAC452.4010301@redhat.com> <46FB527F.2070809@redhat.com> Message-ID: <46FBBA96.8050606@redhat.com> Phil Muldoon wrote: > Apart from the output code, and parsing code in fhpd, is the "get the > location" code placed in a utility class somewhere? Can you give a > programming example of given variable foo, how to get a location or > locations in memory of where it resides? Following is an example taken from /Variable.java/: // Get the DWARF operations that describe the variable's location from its DIE List ops = variableDie.getFormData(frame.getAdjustedAddress()); // Create a LocationExpression from it LocationExpression locationExpression = new LocationExpression(frame, variableDie, ops); // Decode the expression to get the location and create a PieceLocation from it PieceLocation pieceLocation = new PieceLocation(locationExpression.decode(this.getType(frame).getSize())); pieceLocation will now contain the (list of) location(s). You can print it by using its toPrint function, manipulate its bytes, etc. [Refer /Location.java /and /PieceLocation.java/ (or ping me :-) ) for its other functions] From pmuldoon@redhat.com Thu Sep 27 14:21:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 27 Sep 2007 14:21:00 -0000 Subject: New fhpd commands: ptype & plocation In-Reply-To: <46FBBA96.8050606@redhat.com> References: <46FAC452.4010301@redhat.com> <46FB527F.2070809@redhat.com> <46FBBA96.8050606@redhat.com> Message-ID: <46FBBC50.7010300@redhat.com> Teresa Thomas wrote: > Following is an example taken from /Variable.java/: > > // Get the DWARF operations that describe the variable's location > from its DIE > List ops = variableDie.getFormData(frame.getAdjustedAddress()); > // Create a LocationExpression from it > LocationExpression locationExpression = new > LocationExpression(frame, variableDie, ops); > // Decode the expression to get the location and create a > PieceLocation from it > PieceLocation pieceLocation = new > PieceLocation(locationExpression.decode(this.getType(frame).getSize())); > > pieceLocation will now contain the (list of) location(s). You can > print it by using its toPrint function, manipulate > its bytes, etc. [Refer /Location.java /and /PieceLocation.java/ (or > ping me :-) ) for its other functions] Awesome. This is perfect, thanks Regards Phil From cagney@redhat.com Thu Sep 27 14:47:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 27 Sep 2007 14:47:00 -0000 Subject: New fhpd commands: ptype & plocation In-Reply-To: <46FB527F.2070809@redhat.com> References: <46FAC452.4010301@redhat.com> <46FB527F.2070809@redhat.com> Message-ID: <46FBC209.5050507@redhat.com> Phil Muldoon wrote: > Apart from the output code, and parsing code in fhpd, is the "get the > location" code placed in a utility class somewhere? Can you give a > programming example of given variable foo, how to get a location or > locations in memory of where it resides? > Phil, I wouldn't become too attached to this command's implementation as it currently stands; rather just view it as a a glimpse of what is to come. That command reports the expression's result's location which isn't sufficient; instead a walk of the expression tree that generates a list of all referenced locations is going to be needed. I would define the frysk.proc. object interface that you require and expect the location tree walk code to generate that that information; rather than try to have frysk.proc directly access frysk.debuginfo. Andrew From pmuldoon@redhat.com Thu Sep 27 14:53:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 27 Sep 2007 14:53:00 -0000 Subject: New fhpd commands: ptype & plocation In-Reply-To: <46FBC209.5050507@redhat.com> References: <46FAC452.4010301@redhat.com> <46FB527F.2070809@redhat.com> <46FBC209.5050507@redhat.com> Message-ID: <46FBC3D0.3060305@redhat.com> Andrew Cagney wrote: > Phil Muldoon wrote: >> Apart from the output code, and parsing code in fhpd, is the "get the >> location" code placed in a utility class somewhere? Can you give a >> programming example of given variable foo, how to get a location or >> locations in memory of where it resides? >> > Phil, > > I wouldn't become too attached to this command's implementation as it > currently stands; rather just view it as a a glimpse of what is to > come. That command reports the expression's result's location which > isn't sufficient; instead a walk of the expression tree that generates > a list of all referenced locations is going to be needed. > > I would define the frysk.proc. object interface that you require and > expect the location tree walk code to generate that that information; > rather than try to have frysk.proc directly access frysk.debuginfo. That's fair enough. From the observer point of view, all that is needed is a memory location and range - at the first pass. Later on as debug register usage is optimized to not map duplicate/overlapping ranges, it might be more meta-data. Still all of the above (Teresa's work) is neat stuff indeed. Happy to see it in the repo. Regards Phil From kris.van.hees@oracle.com Fri Sep 28 15:47:00 2007 From: kris.van.hees@oracle.com (Kris Van Hees) Date: Fri, 28 Sep 2007 15:47:00 -0000 Subject: Automated build-and-test summary report (2007/09/28) In-Reply-To: <20070928153921.GA8300@oracle.com> References: <20070928153921.GA8300@oracle.com> Message-ID: <20070928154656.GM21435@oracle.com> Please note that the following results are incorrect. The problem is currently being investigated and a new report will be sent out as soon as the problem has been identified and fixed. Cheers, Kris On Fri, Sep 28, 2007 at 11:39:21AM -0400, Kris Van Hees wrote: << Correct part of the report removed. >> > ------------------------------------------------------------------------------ > Package: frysk_fresh > Previous build: 2007/09/27 01:50:01 - 2007/09/27 02:40:15 > Current build: 2007/09/28 01:13:12 - 2007/09/28 01:13:47 > Host: ca-tools4 > Platform: Linux x86_64 2.6.22.5-76.fc7 (F7) > URL http://build.alchar.org/~aedil/rep/ca-tools4/frysk_fresh.20070928-011312.html > First failure: no failures (was test) > > ------------------------------------------------------------------------------ > Package: frysk_incr > Previous build: 2007/09/27 01:12:04 - 2007/09/27 01:50:00 > Current build: 2007/09/28 01:12:05 - 2007/09/28 01:13:11 > Host: ca-tools4 > Platform: Linux x86_64 2.6.22.5-76.fc7 (F7) > URL http://build.alchar.org/~aedil/rep/ca-tools4/frysk_incr.20070928-011205.html > First failure: no failures (was test) From pmuldoon@redhat.com Fri Sep 28 21:21:00 2007 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 28 Sep 2007 21:21:00 -0000 Subject: Optimizing watchpoints Message-ID: <46FD7036.2010500@redhat.com> I wasn't going to do this in the first pass at watchpoints, but I might as well as think on it now. Given that debug registers are very scarce, and that typically there might be a scenario where we could better optimize watching similar addresses and ranges, is there an established protocol for this? I thought about checking addresses and ranges as a simple "we are already watching this address in another register and scope". But as usual things get hairy in C when you add in pointers (that pointer to pointers in structures and so on). I suspect the answer here is "No" but can't help to ask, and establish the conversation ;) Regards Phil From cagney@redhat.com Fri Sep 28 22:43:00 2007 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 28 Sep 2007 22:43:00 -0000 Subject: tag cagney_20070928_pre_rereg Message-ID: <46FD8332.5050400@redhat.com> FYI, I'm changing frysk.proc.Isa* and co to refer to constant objects (e.g., frysk.isa.IA32Registers.EAX) instead of strings (e.g., "eax") where pratical. Doing this will flush out a number of cases where registers are being refered to using different names (e.g., "fop" vs "foo"). As a "just in case", I've dropped the tag cagney_20070928_pre_rereg to identify the start of the more significant changes; and provide a revert anchor. Andrew From pearly.zhao@oracle.com Sun Sep 30 01:10:00 2007 From: pearly.zhao@oracle.com (Zhao Shujing) Date: Sun, 30 Sep 2007 01:10:00 -0000 Subject: [patch] Fix bug 4614, 4619 and 4870 Message-ID: <1191115053.4283.2.camel@linux-pzhao.site> Hi This bug is to fix 4614, 4619 and 4870. Here is what it does: - Change the top confuse text "current program counter" to segment combox box. Users can choose the segment from the combo box to display and adjust the offset by spin button. Some segment is too long to display, it's be handled the by the following rule. - If the specified startAddress is too smaller that the lastKnownFrom value, and the UI can't handle some many data, it would be set to display about 50 instructions at disassembly window and 20 rows at memory window from the startAddress. - It would be handled by the same way if the user only changed the endAddress. - Add warning dialogs when the address can't be accessed and when the symbol is not in current context. The warning messages are as same as these of gdb. -------------- next part -------------- A non-text attachment was scrubbed... Name: dismem0929.patch Type: text/x-patch Size: 41413 bytes Desc: not available URL: From mark@klomp.org Sun Sep 30 19:10:00 2007 From: mark@klomp.org (Mark Wielaard) Date: Sun, 30 Sep 2007 19:10:00 -0000 Subject: Optimizing watchpoints In-Reply-To: <46FD7036.2010500@redhat.com> References: <46FD7036.2010500@redhat.com> Message-ID: <1191179433.3275.14.camel@hermans.wildebeest.org> Hi Phil, On Fri, 2007-09-28 at 22:20 +0100, Phil Muldoon wrote: > Given that debug registers are very scarce, and that typically there > might be a scenario where we could better optimize watching similar > addresses and ranges, is there an established protocol for this? > > I thought about checking addresses and ranges as a simple "we are > already watching this address in another register and scope". But as > usual things get hairy in C when you add in pointers (that pointer to > pointers in structures and so on). We are already doing a simple version of this for low level breakpoints. For each Code observer added at the proc level there is a simple map, BreakpointAddresses, that keeps track of whether or not an actual breakpoint instruction is already there. So whenever a Code observer is added or removed at a particular address the BreakpointAddresses map is consulted to see whether an existing one can be reused, or should be kept, because other Code observers are monitoring the address. For watchpoints you don't just have simple addresses, but also a range. That makes your 'overlapping' detection a little less straightforward than in the Code observer case. But BreakpointAddresses does already give a simple version that can find breakpoint addressses given a range of memory, public Iterator getBreakpoints(long from, long till). Something like this, based on a TreeSet of addresses plus ranges can probably be used to implement your watchpoint address range overlapping detection. I wouldn't worry too much about the particulars of hairy C structures. That should be handled at a higher language level by installing multiple proc watchpoint observers. Cheers, Mark