Support dumping user-space stack from kernel

From eLinux.org
Jump to: navigation, search
Summary
Support dumping user-space stack from kernel
Proposer
Tim Bird, Sony Mobile
Status
Not selected in 2013 to be sponsored by the CE Workgroup

Description

Currently, a function like dump_stack() (which internally calls dump_backtrace()) is limited to showing the the dump of kernel stack only.

In some situations it would be useful to get the call stack of the user level process also, instead of just the kernel's call stack. This feature could be used to determine what user-space activity was responsible for what kernel actions.

It will be nice if this feature could be enabled with a kernel config option.

In conjunction with this, it would be nice to support a system-wide tracing function, which could trace both user-space and kernel space. This would include a simple method in userspace to show the both user-space and kernel-space functions, with arguments and return values.

Other existing systems, such as strace, ltrace and ftrace, show parts of the full sequence of execution, but not all of them. It would be nice to create an easy tool similar to strace, which showed the functions through all levels of the system.

As an example, when running a program called 'prog1', it would be nice to collect and display:

  • all function/library all from prog1 in user-space,including the arguments for each call and the return values
  • all system calls made by prog1, including arguments and return values
  • all the function calls in kernel-space launched resulting from prog1 (all processes / threads) including what happens during system call, irq, softirq, and tasklets)

Related work

  • LTTng - has a user-space tracer (not the same as monitoring return values)

Scope

Unknown

Contractor Candidates

None yet.

Comments

Reasons for CEWG not selecting this project

Most members thought LTTng already supported this sufficiently. If done from kernel, this would require user-space symbols in the kernel, which seemed difficult in memory-constrained devices. Also, no bid was received for this project.