Add vcore_entry to vcpd (XCC) (1/2)
authorKevin Klues <klueska@cs.berkeley.edu>
Sat, 18 Jul 2015 16:45:21 +0000 (09:45 -0700)
committerBarret Rhoden <brho@cs.berkeley.edu>
Wed, 22 Jul 2015 15:09:26 +0000 (11:09 -0400)
commitcffb4c2453aad856546f5d52e12f3006c6b32f01
tree7b7677855aa8e77db26d24395fc95f15647dc68c
parente55c311d680c4eb5e45ea7339dae9fa305fb321b
Add vcore_entry to vcpd (XCC) (1/2)

These next two commits finalize the migration of setting up a vcore
specific entry point in vcpd instead of always reentering userspace via
the _start function. Having our _start function be reentrant has always
been a hack, and this patch finally removes all remnants of system dependant
process entry code in glibc. We now only enter a process via the _start
function provided by sysdeps/x86_64, and there is no custom
initialization code forced into crt1.o via init.c. All startup code
now runs properly inside the vcore_lib_init() constructor function from
parlib.

Logically, these two commits are part of a single patch
(i.e. the xcc will not compile until both of them have been applied),
but it is clearer if I break them up into separate commits.

In this first commit, I simply export our tls related functions from
glibc through stdlib instead of bundling them in our init.c file.
Previously, we (hackishly) #included tls.c inside of init.c in order to
make its functions available to __libc_vcore_entry() (this was necessary
because init.c is part of crt1.o and simply including tls.c as part of stdlib
is not sufficient to give init.c access to its functions). In the
following commit we do away with init.c completely, so this is no longer
an issue.
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/Makefile