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: [Ksummit-2008-discuss] DTrace


On Mon, 2008-06-30 at 13:48 -0700, David Miller wrote:
> From: Arnaldo Carvalho de Melo <acme@redhat.com>
> Date: Mon, 30 Jun 2008 17:22:33 -0300
> 
> > Em Mon, Jun 30, 2008 at 04:10:31PM -0400, Theodore Tso escreveu:
> > > On Mon, Jun 30, 2008 at 03:25:33PM -0400, Frank Ch. Eigler wrote:
> > > Stupid question --- has anyone thought about writing tools to strip
> > > out specific debug information not needed by Systemtap?  For example,
> > > I assume systemtap doesn't need the line number information, since you
> > > can't set probes on arbitrary line numbers (and even if you could,
> > > such tapsets would be so brittle that it wouldn't be funny); so would
> > > the debuginfo files be smaller if that information were stripped out?
> > > I understand that this would make the files less useful for
> > > kdump/crash, but for systemtap only users, it might be quite useful.
> > > What about stripping out the text segment of the object files, so you
> > > aren't storing the information twice on disk, or compressing the
> > > debuginfo files so they take up less room on disk?
> > 
> > Yes, its called CTF, Compressed C Type Format, in DTrace land:
> > 
> > http://opensolaris.org/os/project/ppc-dev/task_map/ctf/
> > 
> > DaveM wrote a CTF loader that I included in my dwarves package, so that
> > we can pretty-print and use all the other features in pahole on files
> > with CTF sections, such as the Open Solaris kernel and the userland
> > binaries, that all ship with CTF embedded, dispensing the usage of
> > -debuginfo packages, all AFAIK.
> 
> One thing you lose with CTF is the stack unwind tables,
> and I don't know if systemtap needs that or not.

The answer to that is "sort of".  It doesn't need them for the probes
because they're constructed using the debugging information for the
routine.  Its track and frame tracing code do use the unwind
information ... but that's currently part of its runtime arch specific
unwinder; that's one piece I think we can fold into the in kernel
unwinders instead, so at the end of the day I think you can get it to
"no".

> If someone can state what the absolute minimum requirement
> is for systemtap to be able to analyze a binary properly,
> we can figure out if CTF provides it.

In order to insert identify probe points, it needs the debug information
that identifies routines parameters and types.  Then it needs all of the
information to identify the types of these (including nested types).

Right at the moment, with its ability to insert probe points at line
numbers and view local variables, it seems to need all of
the .debug_line stuff.  However, with markers I could see that being
dumped (at least for production kernels ... as a developer, I still
rather like the ability to probe a particular line in a file).

If you think in terms of dwarf, then everything that C uses, it probably
needs.

James



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