From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6538 invoked by alias); 27 Feb 2007 13:55:35 -0000 Received: (qmail 6530 invoked by uid 22791); 27 Feb 2007 13:55:33 -0000 X-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_50,FORGED_RCVD_HELO,TW_FH 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, 27 Feb 2007 13:55:29 +0000 Received: from dijkstra.wildebeest.org ([192.168.1.29]) by gnu.wildebeest.org with esmtp (Exim 4.43) id 1HM2oT-000691-2T for frysk@sourceware.org; Tue, 27 Feb 2007 14:56:19 +0100 Subject: Fosdem impressions, frysk, packaging, tracepoints, kprobes and gdb From: Mark Wielaard To: Frysk List Content-Type: text/plain Date: Tue, 27 Feb 2007 13:55:00 -0000 Message-Id: <1172584523.3777.66.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/msg00163.txt.bz2 Hi, I was away for the last 4 days and also attended Fosdem this weekend in Brussel http://fosdem.org/2007/. That was a blast. I was mainly there to see how Sun and the GNU communities can work together on the future of Java now that Sun is in the process of releasing all parts of their implementation under the GPL. This was all very promising. Even though there are still some holes and details to work out. I do think that in a year choosing java as an implementation language on GNU/Linux platforms will be much more accepted. But I also got a chance to talk with various random people about Frysk. There were people interested in packaging Frysk for other distros (like Mandrake), but apparently they have some trouble with how we depend on things we import into our source tree like junit. I will try to get them to post to the Frysk list since I could immediately figure out what their exact problems were. While talking about Frysk with other people I did notice that I am still missing some of the bigger picture. While I can clearly explain how our tracing and monitoring is different for things like systemtap, valgrind and oprofile, it is harder to explain how we will inter-operate with things like that. And there is a huge interest to see how we are different and complementary to gdb. This came a bit as a surprise to me since I hadn't seen Frysk as that related to gdb or full-blown debuggers before. But now that I played a bit with the fhpd tool it is clear we should have a much better story how we are tackling the same kind of problems gdb is trying to solve. It looks like we could actually attract some people to the project if we just had a page explaining what kind of problems you might want to do with gdb but which would be much easier to solve with Frysk, and the other way around. We do have some high-level overview in our FAQ http://sourceware.org/frysk/questions/ about comparisons with adb or sdb (both of which I don't really know how they compare with gdb), but nothing about the techniques and libraries gdb uses versus those used by frysk to get at the same kinds of information. Driving home the point that we might actually share much more ideas with something like gdb was the talk by Jim Blandy on gdb, tracepoints and kprobes for debugging the linux kernel you are running on your machine. This was really fascinating and he gave a very impressive demo of collecting live trace data on the machine he was giving the presentation on and then using the captured information to drive gdb to show the call-stack, registers, function arguments and contents of various structs passed around at various times during the trace. http://www.red-bean.com/trac/tracepoints I forgot to ask him how gdb can do this in user space. In kernel space they are able to use kprobe handlers to collect the information and then export them through the /proc interface for gdb to get at (to be replaced by sysfs and kobjects). There is an old article on tracepoints in gdb for embedded systems: http://sourceware.org/gdb/talks/esc-west-1999/ But as far as I can tell that makes use of the fact that on the embedded device gdb and the inferior both run in a shared memory space. The tracepoint infrastructure is so useful that I think we should definitely look into sharing ideas and implementation techniques with gdb. Cheers, Mark