This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Discussion at Linux Foundation Japan Symposium


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]