Fixes casting error

int -> long, when passing via a void *.
x86_64: kernel trap/interrupt handling

Worked for breakpoint and a self-ipi.  Vcore stuff is turned off til I
get the kernel sorted.
x86: pmap boot lowmem unmapping

We need to be able to unmap the 1GB physical memory identity map.  One thing
holding this back was the GDT PD pointing to physical memory, instead of
virtual memory.
Cleans up sysenter_init

It's existence is arch specific, so we don't really want it in kernel_init (or
riscv) and within x86, each subarch has different ways to set it up.
x86_64: smp_boot

Also fixes an old bug where smp_boot was treating the boot lock and sem as if
they were 32 bit (they are 16).
Fixes fill-kfs

Wasn't removing the libs or bins due to missing trailing slashes.
Elf loader 32/64 bit checks

KERN64 was a riscv-only thing.  CONFIG_64BIT is arch-indep (and set by
Kconfig).  Also, x86_64 can't handle 32 bit elves, though riscv can.
x86_64: pop non-sysenter TFs, fixes segmentation

Apparently we do need some data segmentation, at least for the SS, when popping
via iretq into userspace.  I haven't needed it for the kernel yet.  Note the
segment limit/base are ignored (they can't express 64 bits), but things like
the DPL and the W bit seemed to be checked.
x86_64: GS base work

The kernel uses GS base to point to pcpu info, and will make sure this is set
up on entry.  It's also important to reset KERN_GS_BASE before we reenable
interrupts.  The assumption is that on entry from any trap/irq, that the
correct kernel GS base is in KERN_GS_BASE.

We don't actually need to swapgs in trap and irq code, but it'll make it easier
to save the user contexts directly into pcpui->cur_tf in the future.

Also note that we're not even going to bother saving and restoring fs and gs -
just the base registers.  This also goes for ds and es, meaning it is possible
for one application to see the ds of a previous program running on that core.
AFAIK, the hardware just ignores DS and ES's internal registers, so if a
program randomly sets DS, it shouldn't hurt the kernel or another process.
x86_64: tracks stacktop in pcpui for sysenter

Would be nice to avoid having per-core GDTs and TSSs too, but the traps and irq
stuff pushes everthing before we get control.  Oh well.
x86_64: Syscall/Sysenter/int 0x80 (XCC)

Userspace can make system calls with either syscall (aka sysenter in the
codebase, 'syscall' is pretty generic) or int 0x80.

Rebuild the toolchain to use this, though _start probably doesn't work well as
is.  If you really want to test off this commit, write your own C program,
define _start, and compile with a non-cross gcc:

$ gcc minihello.c -o minihello -static -nostdinc -nostartfiles
x86_64: TLS FS base changing 'fast call' (XCC)

For systems that don't support reading/writing the FS base from userspace, we
have a fast path in the kernel to change the FS base.  We don't save or restore
anything, nor do we enter the main syscall path.  Hopefully that will be
reasonably fast.

This does impact the normal syscall path, albeit slightly.  If you know you
have hardware (Ivy Bridge or later) that supports WRFSBASE, then you can
disable this option.  Be sure your userspace knows what to do.

Reinstall your kernel headers.
Fixes memory checking bug on syscall structs

The long term fix is to have the kernel handle page faults on user addresses,
instead of looking at the page tables (which is insufficient unless we pin, and
is slow regardless).
x86_64: sets the desired dynamic linker (XCC)

This uses the same linker pathname for 32 and 64 bit.  We aren't set up for
multiarch, or otherwise having both 32 and 64 bit binaries on a 64 bit system.
Allow file mmaps beyond the end of the file

64 bit glibc libraries have an unaligned 2MB hole in the middle, and
ld.so just maps that extra space in the original mmap call, then
mprotects it to PROT_NONE.  Fair enough.
x86_64: glibc TLS (XCC)

get and set_tls for glibc.  This doesn't attempt to use WRFSBASE (if
present) yet.

Rebuild glibc; make sure to copy the tls.h from the -ros directory (or
just make clean).
x86_64: save/pop kernel contexts

Kernel contexts are now arch-specific, and x86_64 is using SW contexts
(smaller, simpler).
x86_64: all apps compiled with -mno-red-zone (XCC)

The red-zone is an ABI specification, allowing the compiler to use 128
bytes below the stack pointer.  This helps with some leaf functions.
We make a bunch of assumptions about being able to use the area below
the stack for popping user contexts, so we can't allow the red-zone
optimization.  There is a similar issue with interrupts in the kernel
(given our current interrupt handling strategy).

Copy over ros64.h and rebuild GCC.
x86_64: user space TF handlers

Saving and popping HW and SW TFs.  Might be a few bugs with it still.
Note the x86_64 port uses SW contexts for syscalls, so we might have
some subtle issues out there.

At this point, busybox, signal handling, and regular pthread_test work.
x86_64: secure SW contexts

The kernel can legitimately be asked to pop a SW context from VCPD.  If a
syscall (a SW ctx) is in the kernel when a __preempt arrives, that SW ctx will
be saved into VCPD.  If that VC was in vcore context (notifs disabled), then
the kernel will secure and restart it next time that vcore runs (change_to or
__startcore).