Re: Some notes on translation

[Tom Zanussi <zanussi at us dot ibm dot com>]

Ulrich Drepper wrote:
> Tom Zanussi wrote:
>    > In my experience DWARF2 is not as easy to use as it should be.
> >
> > That's also what I've heard - all the more reason to start now.  This
> > could be a tiny first step toward the much-desired dwarf2 library.
> 
> As Frank mentioned, libelf already has a DWARF library: libdw.  This is
> not the same as SGI's library.  The latter is unusable since the memory
> handling cannot be done without leaking.
> 
> The header for libdw is not yet installed since I didn't want to expose
> the interface until this is needed.  I can do this anytime, though.  And
> as far as higher-level functionality which is needed: just let me know
> what is needed.  Describe the problems to solve and I can add
> appropriate functionality to the library.
> 

Thanks, good to know.

> 
> > I'm
> > not sure why we'd want to use /proc in place of netlink in any case -
> > also I thought putting new stuff in /proc was discouraged anyway.
> 
> /proc seems like the wrong place for many things.  But there are a
> number of other filesystems available.  There are special filesystems
> for high-bandwidth kernel<->userland transfer etc.  And it is not hard
> to write a new filesystem.
> 

Yes, a 'tapfs' pseudo-filesystem might have some interesting
possibilities.  For one thing, it could provide a nice namespace for
probes - each probe would be uniquely identified by a path in the
filesystem, and 'providers' would create and manage their own subtrees
in the fileystem e.g. the syscall provider could create a
/mnt/tapfs/syscalls directory in turn containing a subdirectory for
each of the probes it supports.  Maybe there would be a few files in
each probe directory, like 'output', which is what would be read from
to get the current state of the probe data like what's currently being
done with the /proc file, and 'enabled' and 'registered', which would
be r/w files that would register/deregister and enable/disable probes.
Currently, registering a probe means also enabling it, but maybe it
would make sense to separate the two.  That way, providers could
provide information as to what they're capable of instrumenting in the
form of files in the filesytem, without having to actually insert a
probe.  The tree could then be traversed to figure out what is
available, and probes could be enabled/disabled by writing 1/0 to the
'enabled' file.  The 'registered' file could contain useful
information about the probes, to be displayed by a systemtap probe
enumeration command; if it contained the actual systemtap script, you
could tar the entire filesystem and have a snapshot of exactly what
was running at the time, which might be useful for debugging...

One of the most imporantant providers would be the 'fbt' (function
boundary tracing) provider.  Perhaps it would mirror the kernel source
tree under /mnt/tapfs/fbt and probes would be put into a subdirectory
for the corresponding source file
e.g. /mnt/tapfs/fbt/kernel/fork.c/do_fork would be the probe currently
instrumenting do_fork() (not sure how we'd handle the case of multiple
probes at a single location).  Other providers might provide their
probes as links to files in the fbt tree e.g. the syscall provider
might just provide a set of symlinks to the corresonding
subdirectories in the fbt provider (since the fbt subtree would change
across kernel versions, it probably wouldn't make sense to do this
except for the most stable APIs)...

Thanks,

Tom