Re: runtime library wrapper for program counter

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -


> I like the PC/IP wrapper idea.

The term "wrapper" is not quite right.  This is not wrapping some
existing function, just providing a new architecture-abstraction
facility, one of several we'll need.  The more general case is also
needed: mapping from dwarf register numbers to entries in the same
pt_regs structure.


> I also like the idea of wrapper function for process
> credentials. This call gives process credentials like PID, PPID,
> UID, EUID, GID [...]

These values can be accessed in an architecture-neutral way straight
from the translator's C output code.  I imagine mapping script
variables like "$pid" to fragments of code to be inlined in the
C output.  In this case, it'd expand to something like

  cur_stackframe->tmp_pid = (in_interrupt() || !current)
                            ? 0 : current->pid;

There is no need for a call into a runtime library for something
simple like this.


> Another wrapper similarly would be print the call stack. 

Printing is too particular.  In order to process a stack trace in a
script, some storable value representation is needed.

> For now we can limit to kernel stack but in the future similar
> functions could exist for user stack and full stack.

(Modulo the gradually better-understood copy_from_user issues.)


> Another useful runtime function for filtering would be who called
> this routine.  One of the ways to define a probe is run the probe
> handler if this function is called from a specified function. For
> this we need to know the caller.

More generally, a function that maps PC addresses to function names
could be handy.  Or not: that could all be left to the translator to
deal with statically (from debug info / symbol tables), and not
dynamically during run time (from kernel introspection functions).

Remember, all these runtime functions have to operate with minimal
assumptions about kernel state.  They must have minimal impact
(temporary storage, runtime, stack depth, I/O, etc.).


- FChE