1 files changed, 81 insertions, 0 deletions
diff --git a/usr/klibc/arch/README.klibc.arch b/usr/klibc/arch/README.klibc.arch
new file mode 100644
index 0000000..662b9d3
--- /dev/null
+++ b/usr/klibc/arch/README.klibc.arch
@@ -0,0 +1,81 @@
+To port klibc to a new architecture, you need:
+
+a) A directory structure
+
+Each archtecture has a klibc/arch/ directory, which should include an
+MCONFIG and a Makefile.inc file, and an include/arch/ directory, which
+includes some architecture-specific header files, including
+klibc/archconfig.h.
+
+
+b) Architecture-specific configuration
+   (include/arch/*/klibc/sysconfig.h)
+
+This file can set configuration variables from
+include/klibc/sysconfig.h.
+
+
+c) Startup code
+   (klibc/arch/*/crt0.S)
+
+The crt0.S assembly routine typically corresponds to the following
+pseudo-C code.  In addition, each architecture needs any support
+routines that gcc-generated code expects to find in the system library
+-- Alpha, for example, needs divide subroutines.
+
+The "getenvtest" test program is a very good test for proper crt0.S
+functionality.
+
+
+extern __noreturn __libc_init(void *, void *);
+
+__noreturn _start(void)
+{
+  void *elf_data   = get_elf_data_address(); /* Usually the stack address */
+  void *atexit_ptr = get_atexit_ptr();       /* Usually in a register */
+
+  /* Some architectures need this for debugging to work */
+  setup_null_stack_frame_if_necessary();
+
+  __libc_init(elf_data, atexit_ptr);
+}
+
+
+d) A setenv implementation
+   (klibc/arch/*/setjmp.S, include/arch/*klibc/archsetjmp.h)
+
+On most (but not all!) architectures, this entails creating a setjmp
+buffer big enough to hold all callee-saved registers, plus the stack
+pointer and the return address.  In setjmp.S you have:
+
+* A "setjmp" function that writes out the callee-saved registers, the
+  stack pointer and the return address to the buffer pointed to by the
+  first argument, and then returns zero normally.
+
+  On some architectures you need to take some kind of action to make
+  sure the contents of the stack is actually manifest in memory and
+  not cached in the CPU.  In some cases (e.g. on SPARC) this will
+  automatically spill the registers onto the stack; then they don't
+  need to be spilled into the jmp_buf.
+
+* A "longjmp" function that read back these same registers from the
+  jmp_buf pointed to by the first argument, and returns the second
+  argument *to the address specified in the jmp_buf*.
+
+  On some architectures you need to take some kind of action to flush
+  any cached stack data or return stack.
+
+
+e) Any support functions needed by gcc, *unless* they are in libgcc
+  *and* libgcc is usable for klibc on your particular platform.  If
+  libgcc isn't usable for klibc (on MIPS, for example, libgcc is
+  compiled in a way that is not compatible with klibc) there are
+  reasonably good clones of most of the libgcc functions in the libgcc
+  directory.  To use them, add them to ARCHOBJS in
+  klibc/arch/*/Makefile.inc.
+
+
+f) A link location for the shared klibc.  This should be specified in
+  SHAREDFLAGS in klibc/arch/*/MCONFIG.
+
+  This is not applicable to no-MMU architectures.