cs avoidance

if it's a numeric address don't bother with CS.

Does it work? I don't know.

Signed-off-by: Ron Minnich <rminnich@gmail.com>
Fixes IRQ enabling when kthreads unblock

When kthreads unblocked, IRQs would be disabled, regardless of whether or not
they were on when the thread tried to down a semaphore.  (With the exception of
the sem_down_irqsave, which already managed that).
Increases the op backtrace buffer

Our callgraphs are often deeper than 8, which leads to not properly attributing
deep functions to their older ancestors.  The downside is the buffers (on the
stack) are bigger, increasing our chances of running off the stack, and
increasing the overhead of the backtrace.  If the stack is a problem, we can
malloc the buffer or something.
Attempts to fix uth_disable_notif()

There were two problems with disabling notifs.  First, using the uthread's TLS
is a bad idea.  The uthread might not have it, and then it's using the vcore's
TLS.  That alone might be okay, since the uthread pins itself to the vcore
(we'd have to do the check after disabling migrations and other shit).

The bigger issue is with locks grabbed in uth context and unlocked in vcore
context.  When we reenable, we would not reenable notifs, nor even adjust the
depth counter.  Vcore context just blows past those checks.  Likewise, uthread
code will never unlock it, since the unlock calls typically happen in the
uthread_yield() callbacks.  We could try and have the vcore code figure out who
was locking and adjust the depth, but that's just a pain in the ass (and
doesn't work well with locks help by both vcore context and uth code (e.g. the
pthread runqueue lock)).

This commit changes three things: uses the uthread struct for the depth, has
vcore code reset the depth during yield, and does some cleanup/debugging.

The rule for uthread code that grabs locks (or otherwise disables notifs) is
that vcore context will reset the disabled depth to 0, and uthread code should
not try to reenable notifs past the yield point.  Vcore code will enable notifs
when it relaunches the uthread.  There might be issues with this, where some
uthread disables notifs, makes some call that yields (or blocks on a syscall!)
and then reenables notifs.  Note that PDR locks count as enable/disable sites.

For cleanup, I don't see why there would not be a current_uthread, and put in
an assert to catch things (for now).
User libraries depend on their dependencies .a's

The previous commit exposed an issue where libraries would not rebuild if their
dependency was newer.  The old style just made sure the dependencies rebuilt
first, but not that the libraries would actually rebuild.  Their linking needs
to depend on the dependencies output archive (e.g. libparlib.a).
Rename all relevant stuff in gcc to akaros

This is the first step in migrating our cross compiler over to cross
tools.

For default compiler defines, I left __ros__ and friends in there for
the moment.  We should probably phase this out over time.
Migrate glibc stuff to 'akaros' as well
Update the Makefile renaming ros->akaros
Update patches for ros->akaros
Update CROSS_COMPILE for ros->akaros
Make the CXX be called ucb-akaros
Figure out where to install-libs

Working towards getting crosstools working to build our cross compiler,
they use the sysroot-style installation.  We need to install our libs in
a different place depending on which style we are using.
Commit generated file to remove error/warning

This file eventually gets generated and the CXX build process completes,
but during the build we see a bunch of errors because it gets generated
too late (or something).  Its all black magic in the corss compiler
build....  We should probably revisit this at some point though.
Add working crosstools config