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


Hi Ted,

Theodore Tso wrote:
> 3) Actually try to find a way for Systemtap to be more useful
> *without* waiting for Godot^H^H^H^H^H^H some hypothetical future,
> probably at least 18-24 months away, when new gcc and toolchain
> becomes available that will magically and mystically Solve All
> Problems.  Consider how ftrace works; it very cleverly uses/abuses the
> profiling hook inserted gcc -pg.  Note that it doesn't wait for magic
> new capabilities in the toolchain.  

Actually, I'd like to find a way (or a bridge of the gap amoung us)
to solve this problem positively...

Hm, what issues are making systemtap useless?

- Using debuginfo
 Pros.
  - with debuginfo, systemtap can access local variables and
    query members of data structures by name.
  - debuginfo also enables line-by-line tracing(need to be improved),
    userspace probing, and so on.
  - kernel developers can build its debuginfo by themselves.
 Cons.
  - debuginfo is too huge to distribute all developers and users.
  - debuginfo is too huge and complex so that it increases compilation
    time and disk space consumption.
  - most of developers may not need line-by-line tracing(and it
    might not work in some cases). they just want to trace function
    boundary (maybe, with parameters).

- Module-base
 Pros.
  - Systemtap allows you to filter logging information based on conditions.
  - no-module configuration is not popular...
 Cons.
  - some people build kernel with no-module configuration.

- Non upstream first
 Pros.
  - systemtap is just a tool.
  - systemtap can catch up with upstream in several days after releasing.
 Cons.
  - systemtap works as a tool, but it strongly depends on the kernel.
    if upstream kernel is updated, systemtap will be broken.
  - because of waiting for systemtap update, kernel developers can't
    use systemtap on the development kernel.
  - maintenance cost will increase, especially on runtime and tapset.
  - utrace and uprobe are a part of kernel, but no patch was posted
    these months.

Are these items right? (I think some items should be updated.)


> Another solution which I've suggested in the past, but which has been
> utterly ignored, (since, after all, what does a Kernel Developer
> know?) is to simply generate the debuginfo information on demand so
> the function parameters on entry can be decoded.  We have the header
> files after all, so it shouldn't be hard to generate a pseudo function:
> 
> extern int foo_kernel_function(struct file *f, off_t offset, size_t len, 
>        void *ptr)
> {
> 	return 0;
> }
> 
> ... and then use that to generate the debuginfo information for that
> information so Systemtap knows how to decode the function parameters
> on entry.  This would be enough such that Systemtap can probe any
> public function in System.map --- and obtain the function parameters
> for any function which is present in the kernel headers --- all
> without requiring users to download or create hundreds of megabytes of
> largely useless (on a value-per-megabyte-basis) !@#!@# debuginfo
> information.

Good idea! It seems much easier than introducing new CTF-like compressed
debuginfo... why did anyone ignore...?

Thank you,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com


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