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

index 9da83a4..b3608db 100644 (file)
@@ -41,8 +41,7 @@ ifeq ($(subdir),stdlib)
 sysdep_routines += serialize
 endif
 
-# Vcore initialization functions. We want this in ctr1.o so we have to build
-# them in the csu subdir and place them in a spcial file called 'init'. */
-ifeq ($(subdir),csu)
-sysdep_routines += init
+# TLS related functions
+ifeq ($(subdir),stdlib)
+sysdep_routines += tls
 endif