Re: Getting systemtap examples working with --bpf backend

[William Cohen <wcohen at redhat dot com>]

On 5/22/19 4:51 PM, Frank Ch. Eigler wrote:
> 
> wcohen wrote:
> 
>> global __gtod_offset = 0 /* FIXME need to set appropriately on startup */
> 
> Is there a standard bpf function to get this value?  If so, it's trivial
> to call it from a probe-begin and initialize this global.  If not, it's
> a less trivial job for it to get a reserved spot in the same global
> array where the bpf runtime communicates exit-ness with stapbpf.  Then
> stapbpf could initialize this shared global at its startup.  Or a fake
> stapbpf-special bpf function could provide this value, and again a
> probe begin could save the value.
> 
> - FChE
> 

Hi,

The BPF helper libraries have a ktime_get_ns function to get the time, but there isn't a helper function to get that offset between start of the epoch and when the machine powered on, what ktime_get_ns uses as the start of time.

What might be feasible is to probe begin run in user space to compute that offset and put it in a bpf map.  According to https://blogs.oracle.com/linux/notes-on-bpf-3 :


Map actions

We can create/update, delete and lookup map information, both in BPF programs and in user-space. User-space map interactions are done via the BPF syscall. Their function signatures are slightly different to those of their in-kernel BPF program equivalents. In tools/lib/bpf/bpf.c wrappers for these actions are present:

This technique might also be useful for initialization information like syscall numbers<->names and other constants rather than trying to put everything into space constrained bpf code. However, not sure how that is going to be managed if multiple systemtap scripts are kicked off.

-Will