From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26819 invoked by alias); 24 Dec 2008 18:14:18 -0000 Received: (qmail 26812 invoked by uid 22791); 24 Dec 2008 18:14:17 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from BISCAYNE-ONE-STATION.MIT.EDU (HELO biscayne-one-station.mit.edu) (18.7.7.80) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 24 Dec 2008 18:13:35 +0000 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id mBOIDRmj012327; Wed, 24 Dec 2008 13:13:28 -0500 (EST) Received: from closure.thunk.org (c-98-216-98-217.hsd1.ma.comcast.net [98.216.98.217]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id mBOIDQvl000869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Dec 2008 13:13:27 -0500 (EST) Received: from tytso by closure.thunk.org with local (Exim 4.69) (envelope-from ) id 1LFYEY-0001AW-NI; Wed, 24 Dec 2008 13:13:26 -0500 Date: Wed, 24 Dec 2008 21:02:00 -0000 From: Theodore Tso To: Masami Hiramatsu Cc: Roland McGrath , "Frank Ch. Eigler" , systemtap@sources.redhat.com Subject: Re: Discussion at Linux Foundation Japan Symposium Message-ID: <20081224181326.GX23723@mit.edu> References: <20081221003831.GG24081@redhat.com> <20081222181921.GH23723@mit.edu> <20081222203747.GA4195@redhat.com> <20081223211306.67D29FC3B7@magilla.sf.frob.com> <49516247.50704@redhat.com> <20081223222043.C6AF3FC3B7@magilla.sf.frob.com> <495173A8.7060405@redhat.com> <20081224033922.A7942FC3B7@magilla.sf.frob.com> <4951D1F0.7000307@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4951D1F0.7000307@redhat.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Scanned-By: MIMEDefang 2.42 X-Spam-Score: 0.00 X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2008-q4/txt/msg00645.txt.bz2 On Wed, Dec 24, 2008 at 01:08:48AM -0500, Masami Hiramatsu wrote: >> I don't think I understood this sentence. I certainly would be much >> happier if we'd embarked on this work two years ago, but we didn't, >> and we have yet to really begin. The idea that it could take >> anything like two years of actual development on this to produce >> results seems just ludicrous to me, if that's what you meant. >> Unless the effort goes horribly awry, I'll know a great deal more >> concrete about it in a month, and the hope going in is to have quite >> a lot of it done in two months. > > Would you mean you can release a usable prototype in two months > if no trouble? Great! If so, I think it's enough short for us and kernel > developers to use the tool. The key question is whether said prototype is a stand-alone tool, or something which is a patch to the current development tree of gcc. If the development work is merely a way to compress the debuginfo, either by outright using gzip, or eliminating common type information ala Open Solaris' CTF, it could very well be a standalone tool, at which point two months is really no big deal. (A tool that stripped out line-by-line debuginfo but left function parameter information might also be useful, given my experience about exactly how useful per-line probing has actually worked for me in practice.) If however the patches need to go into the gcc development, we end up getting blocked for the next gcc release, that could be a very long time. Even after the compiler is released, the Linux kernel is very sensitive to compiler vagrancies. Regardless of whose side you chose on the "the C spec allows us to do this, and any code that relies on previous behaviour is buggy" vs. "no sane intepretation of the standard would allow that; it's the compiler's fault", the fact of the matter is that a bleeding edge compiler can't be trusted to compile a Linux kernel w/o bugs for quite some time --- whether you call it making changes to the kernel to work around gcc bugs, or fixing bugs in the kernel, the net result is the same. Note that some of the changes to allow line-by-line probes to be more reliable in the face of CSE, static function inlining, code reordering, etc., changes almost certainly have to be made to the compiler. Hence, it might make sense to figure out what could be done that does _not_ require gcc modifications, but rather could be done as a standalone program, as well as what a long-term development plan that requires making Compiler toolchain modifications. To be clear, it is the gcc changes that I suspect will require 12-18 months (and so therefore makes me debious it could be done before RHEL 6), because of the gcc release and correct kernel compilation issues. If a prototype of a standalone program which can compress the debug info in two months, that would be highly helpful, I agree. - Ted