This allows running either testrunner.so, or one of the tests (e.g.
test/tst-fpu.so), as they now both export the same entry point.

Used when names in an object may conflict with names in other objects.

Python has no pointers, so it doesn't support %p.  Convert it to %016x.

Use:

  debug("foo %s %x\n", foo.x, foo.y);

Instead of:

  debug(boost::format("foo %s %x\n") % foo.x % foo.y);

note this uses boost::format, not *printf(), so size modifers ("%lx") are
unneeded.

This is only causing confusion; change all callers to add '\n' explicitly
and drop the optional argument.

Variable size trace records.

To conserve space, we now use variable size trace records.  To avoid problems
with wrap-arounds, and with recovering a complete entry at the head of the
ring buffer, we don't allow a trace record to cross a 4096-byte boundary.

When out of memory in alloc_page() or malloc_large(), we used to produce
mysterious assertion failures or aborts. Now print a more user-friendly
"out of memory" error (and abort).

To run the debug build, instead of "scripts/run.sh debug", use
"scripts/run -d".

With a ring buffer, we need to know the size before writing to determine
if we wrap around.

Also fix the numbering.

On a 32-bit system, a 64-bit value need only be aligned to 32 bits, not 64.
Change the code to reflect that.

Tracepoint command line support.

Enable via command line.

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

Will match on tracepoint names.

e.g.

  enable_tracepoint("*function*");

We used to have libz in bootfs.manifest, and now that it was removed, it
needs to be put in usr.manifest... It is needed by Java to load the
compressed jar.

"osv info threads" used to show the switch_to() function for all non-running
threads. Now, it attempts to skip "obvious" functions until finding a less
obvious caller which initiated the final thread switch.

Currently, the mechanism to define obvious functions is pretty crude - it
just considers all functions in arch-switch.hh, sched.cc, sched.hh or
mutex.hh, to be obvious, avoiding showing things like switch_to(),
schedule(), wait_until(). In the future we can refine this definition.
In my opinion it would be best if we could decide on one file (or a small
set of files) which contain all these generic switching/waiting functions
and we'll simply avoid showing anything from these files in "osv info threads".

Since commit 5384840a which changed the way we remember a
non-running thread's rip and rbp, "osv info threads" was broken and
showed question marks for all non-running threads. Now it's fixed
but always shows sched::thread::switch_to() as non-running threads
indeed called this function last.

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).