This is the mail archive of the systemtap@sources.redhat.com 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: Output Redesign in SystemTap Runtime


On Mon, 2005-04-25 at 21:06 -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> > The current hastily-implemented output format in the runtime is
> > inadequate.  I have come to the conclusion that we need to have
> > tagged data in the output stream for the kernel-to-userspace
> > transport.  [...]
> 
> Along with any such proposals, please supply hypothetical script code
> that would use such a system, since of course the runtime does not
> operate in isolation.  For example, do you imagine requiring distinct
> function calls to add various types of tags?  How do you imagine
> "register" and "stack" values/types being generated, passed,
> processed?

OK, I'll try to give a simple example, without knowing much about the
script language.

script:

{
	print ("Hi.  backtrace is");
	stack (1,0);
}

generates C code like:

{
	_stp_print_entry();
	_stp_print ("Hi. backtrace is");
	_stp_stack (1,0);
}

which sends output to stpd like:

<entry uptime_read_proc [1114489190.178160] />
<text>Hi. backtrace is</text>
<stack verbose=1> 0xffffffff801bdb01 0xffffffff801bba8a
0xffffffff80180e72 0xffffffff80181183 0xffffffff8010e51a </stack>

After data collection ends, stpd processes the collected data files and
saves an xml file containing the processed data as

<entry uptime_read_proc 1114489190.178160 />
<text>Hi. backtrace is</text>
<stack> 
0xffffffff801bdb01 : uptime_read_proc+0x1/0x100
0xffffffff801bba8a : proc_file_read+0xea/0x260
0xffffffff80180e72 : vfs_read+0xe2/0x160
0xffffffff80181183 : sys_read+0x53/0x90
0xffffffff8010e51a : system_call+0x7e/0x83
</stack>

Now, if we are doing a dtrace-like experiment and we want simple text
output, then that is stripped out:

Hi. backtrace is
0xffffffff801bdb01 : uptime_read_proc+0x1/0x100
0xffffffff801bba8a : proc_file_read+0xea/0x260
0xffffffff80180e72 : vfs_read+0xe2/0x160
0xffffffff80181183 : sys_read+0x53/0x90
0xffffffff8010e51a : system_call+0x7e/0x83


Adding the tagged data makes it easier to have the postprocessing do
things like perform symbolic lookups on stack addresses. It also gives
us the power to have more complete data saved in the data file for
processing with visualization tools. If we care to define formatting
options in the script language then we can make rules about how stack
backtraces, memory dumps, registers, etc are printed. I'm trying to look
beyond simple text output like dtrace provides and imagine what might be
needed to build complex applications that use SystemTap.

Martin



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