Enable via command line.

usage: --trace=a,b,c,*foo* --trace=bar java.so ...

Will match on tracepoint names.

e.g.

  enable_tracepoint("*function*");

Useful for command line enabling/disabling tracepoints by name.

Initial tracepoint work.

Still some optimization left to do, but the basic framework is ready.

Declare:

  #include "osv/trace.hh"

  tracepoint<int, long> trace_some_event("some_event", "p1=%d p2=%d");

Use:

  trace_some_event(10, 20);

View:

  (gdb) osv trace

Make tracing usable by writing the log to memory rather than the console.
We reuse the log previously used by function tracing (which is switched
to tracepoints, so that common machinery is used).

Instrumenting functions used in the trace machinery causes infinite
recursion.

They're trivial and deserve inlining.

Strangely, the compiler is able to remove the test code (including the
assert) entirely, as it is able to deduce it passed at compile time.

Use the native alignment for speed.

All child threads start running on the CPU which started them, until
migrated later in load_balancer(). Threads with pinned=true are not
migrated. Unfortunately, we forgot to initialize the pinned field
(POD fields are not initialized in C++) - so all threads started
with random, usually nonzero, "pinned" value and as a result all
threads remained on CPU 0!
Now thread migration works as expected.

This allows the log to refer to the tracepoint and thus also the type
signature.

This allows the trace log to refer to the tracepoint.

wait_until made recursive use of wait_guard: It held one around the code
calling wait(), but while still holding it also called mutex_lock() which
also uses a wait_guard internally. This sort of recursive use of wait_guard
is theoretically supported, but messy to debug, so I now changed the code a
bit so only one of them are held at a time (the lock() is outside wait_guard).

In some cases, stop_wait() forgot to call preempt_enable(), leaving
the preemption of this thread disabled, and causing CPU-heavy threads
to continue running for a long time without other threads (or even
load_balance()) getting a chance to run.

This can be used to recover the data types from a raw buffer (i.e. from a
debugger).  We use the Python struct module encoding (I=u32, etc.).

Two styles are supported, a simple one and a flexible one.

To declare and use a simple tracepoint, use:

  tracepoint<u32, u64, char> trace_my_event("my_event", "%d %x '%s'");

  ...

  void my_function(u32 a0, u64 a1)
  {
      trace_my_event(a0, a1, 'x');
  }

where:

  u32/u64/char: the types of the parameters to be used in the tracepoint
  trace_my_event: an identifier (commonly prefixed by trace_)
  "my_event": how the tracepoint is shown in the logs
  "%d %x '%s'": printf/boost::format style format string (auto deduces
                argument types)
  a0, a1, 'x': runtime arguments to be traced

The flexible style allows different type lists used in the tracepoint
function, and in storing.  This allows having the tracepoint snapshot fields
from some object.  You will need to supply a function to convert from the
runtime types to the storage types:

  std::tuple<u32, u64, char> snapshot_my_object(my_object& obj)
  {
    return std::make_tuple(obj.field1, obj.field2, obj.field3);
  }

  tracepointv<storage_args<u32, u64, char>,
              runtime_args<my_object&>,
              snapshot_my_object> trace_my_object("my_object", "%d %x '%s'");

  void my_function(my_object& obj)
  {
    trace_my_object(obj);
  }

Using this style reduces the runtime overhead since 'snapshot_my_object' is
only run if tracing is enabled.

Thread object creation used to leak one page for the FPU state (thanks
Avi for spotting this). Fix this (add a destructor which frees the page)
and add to the test-suite a test for checking that thread creation doesn't
leak memory - and while we're at it, also checked that alloc_page() and
malloc() at various sizes do not leak memory.

We forgot to free the TCB allocated buffer on thread destruction, causing
a leak of around 1000 bytes per thread creation. We still have another
leak (exactly one page per thread object creation) that I'm trying to find :(

Thread's destructor calls join(), which used to hang if called before the
thread was ever start()ed because it would wait forever for the thread
to change its status to terminated. If join() see the thread was never
started, return immediately.

the socket implementation of fo_close() frees the socket structure and that in
turn invokes poll_wake() which uses refcounting as it mess with the file structure.

the following patch increases the refcount by 1 before calling fo_close()
so we avoid entering the free area in fdrop twice.

bug fix: a reference is held by fget(), make sure to release a refcount

It is already deduced using the masklen parameter