From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18811 invoked by alias); 6 Mar 2007 16:02:10 -0000 Received: (qmail 18802 invoked by uid 22791); 6 Mar 2007 16:02:09 -0000 X-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO,TW_GC X-Spam-Check-By: sourceware.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (83.160.170.119) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 Mar 2007 16:02:00 +0000 Received: from dijkstra.wildebeest.org ([192.168.1.29]) by gnu.wildebeest.org with esmtp (Exim 4.43) id 1HOc7q-00052U-UK for frysk@sourceware.org; Tue, 06 Mar 2007 17:02:55 +0100 Subject: Status build From: Mark Wielaard To: frysk@sourceware.org Content-Type: text/plain Date: Tue, 06 Mar 2007 16:02:00 -0000 Message-Id: <1173196916.4257.69.camel@dijkstra.wildebeest.org> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-1.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q1/txt/msg00178.txt.bz2 Hi, Here an overview of what I have been up to last week and what I want to work on next (and wat not - no more warning patrol for now) Was away two days and attended Fosdem. Saw the presentation of Jim Blandy on gdb, tracepoints and kprobes for debugging the linux kernel discussed on the list. http://sourceware.org/ml/frysk/2007-q1/msg00163.html This is fascinating work and gave me a better perspective on what we can also do with Frysk. This needs some thought on how we handle Observers. Currently we assume that when a Observer gets triggered a Task can be told to block. If we want to support more flexible tracepoints, that might fire events for an Observer, but that are not synchronous and/or don't block the process in place, then we need some mechanism to handle that. Also the perspective of "time-shifting" the inspection data was fascinating. We already do this for the event monitor. Reusing collected data in the memory and register views (or throught the fhpd) to step back in time is a very interesting idea. New GCJ hit rawhide. Fixing build problems with this ate up quite some time since two gcj tools we relied on in the build got removed and/or replaced with something that had different defaults. And the new Automake (1.10) in rawhide had some fixes that interfered with our workarounds for those issues in older versions. But the build now works on both old and new fedora systems (modulo warnings, see below). this did result in me having a nice Xen setup for running Fedora Rawhide as guest under a Fedora 6 host, which I really should document since it is a very nice environment for developing (if you have enough memory). Still waiting for new java-gnome builds against new gcj for rawhide to test the gui. But non-gui tests seem to work as well as can be expected with the buggy kernel that ships with rawhide at the moment. Also cleaned up several warnings pointed out by the new ecj in frysk-imports. Resulting in some small bug fixes and removal of lots of unused code. But warning patrol needs to be done carefully. Made one mistake which temporarily broke the new expunit code (fixed now). We should carefully go over the new ecj warnings and decide which ones we find really useful. The way ecj warns about certain things can impact some of the api design (it prefers abstract methods over stub base implementations for example). Waiting for the -Wall/-Werror bug filed by Stephan to be fixed before looking more into this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231020 I will now finally return to the work on making breakpoints and stepping multi-thread safe having had enough of build systems and warning patrol. Trying to come up with a prototype for out-of-order breakpoint stepping for x86 (x86-64 looks much harder) and/or look again at stop-the-world since that would allow much easier reuse for different architectures. Cheers, Mark