On 2023-07-10 17:26:43+0800, Zhangjin Wu wrote:
On 2023-07-08 23:29:58+0800, Zhangjin Wu wrote:
As the environ and _auxv support added for nolibc, the assembly _start function becomes more and more complex and therefore makes the porting of nolibc to new architectures harder and harder.
To simplify portability, this c version of _start_c() is added to do most of the assembly start operations in C, which reduces the complexity a lot and will eventually simplify the porting of nolibc to the new architectures.
The new _start_c() only requires a stack pointer argument, it will find argv, envp and _auxv for us, and then call main(), finally, it exit() with main's return status. With this new _start_c(), the future new architectures only require to add very few assembly instructions.
I like it!
A quick test indicates that the initialization of the stackprotectors could also be moved into the C function.
Cool, do you mean directly call __stack_chk_init() at the beginning of _start_c()?
Yes, exactly.
It also seems like a good opportunity to add some tests for argv/environment variable passing.
Yes, and even further, we can do more on auxv, just like musl does in src/env/__libc_start_main.c, not that urgent currently:
With tests I mean nolibc-test.c to make sure we don't introduce any regressions. Only some tiny testcases to validate that argv and environ are picked up correctly by the startup code on all arches.
libc.auxv = auxv = (void *)(envp+i+1); ... __hwcap = aux[AT_HWCAP]; if (aux[AT_SYSINFO]) __sysinfo = aux[AT_SYSINFO]; ... libc.page_size = aux[AT_PAGESZ]; if (!pn) pn = (void*)aux[AT_EXECFN]; if (!pn) pn = ""; __progname = __progname_full = pn; for (i=0; pn[i]; i++) if (pn[i]=='/') __progname = pn+i+1; __init_tls(aux); __init_ssp((void *)aux[AT_RANDOM]); if (aux[AT_UID]==aux[AT_EUID] && aux[AT_GID]==aux[AT_EGID] && !aux[AT_SECURE]) return; ... libc.secure = 1;And as general note to the full series I think that splitting the arch files is not necessary and confusing.
Ok, welcome to discuss more in this thread:
https://lore.kernel.org/lkml/20230710072340.10798-1-falcon@tinylab.org/and let's choose a better method as possible as we can, Just replied Willy to explain more.
Will do.
Signed-off-by: Zhangjin Wu falcon@tinylab.org
tools/include/nolibc/crt.h | 44 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+)
diff --git a/tools/include/nolibc/crt.h b/tools/include/nolibc/crt.h index 221b7c5346ca..b269294e9664 100644 --- a/tools/include/nolibc/crt.h +++ b/tools/include/nolibc/crt.h @@ -13,4 +13,48 @@ char **environ __attribute__((weak));
The old code seems to avoid putting "environ" into the global symbol namespace. Could this declaration be moved into the function like in getenv()?
ok, do you mean just move it to stdlib.h like this? I moved _auxv (used by getauxv()) to stdlib.h too:
Nevermind, I got confused by the in-function declaration of "extern char **environ" inside "getenv()". Actually this in-function declaration doesn't do anything and can be dropped.
tools/nolibc: move environ and _auxv from crt.h to stdlib.h Move the definitions of environ and _auxv from crt.h to stdlib.h, where the place who uses those definitions. - getenv uses environ - getauxv uses _auxcv Signed-off-by: Zhangjin Wu <falcon@tinylab.org>diff --git a/tools/include/nolibc/crt.h b/tools/include/nolibc/crt.h index b269294e9664..d2f84cbe73d0 100644 --- a/tools/include/nolibc/crt.h +++ b/tools/include/nolibc/crt.h @@ -10,14 +10,13 @@ #include "compiler.h" #include "crt_arch.h" -char **environ __attribute__((weak)); -const unsigned long *_auxv __attribute__((weak)); - int main(int argc, char *argv[], char **envp); static void exit(int); void _start_c(long *sp) { + extern char **environ; + extern const unsigned long *_auxv; int argc, i; char **argv; char **envp; diff --git a/tools/include/nolibc/stdlib.h b/tools/include/nolibc/stdlib.h index 2f9b4b3c6d26..5eadadc2d0f5 100644 --- a/tools/include/nolibc/stdlib.h +++ b/tools/include/nolibc/stdlib.h @@ -14,6 +14,9 @@ #include "string.h" #include <linux/auxvec.h> +char **environ __attribute__((weak)); +const unsigned long *_auxv __attribute__((weak)); + struct nolibc_heap { size_t len; char user_p[] __attribute__((__aligned__));
const unsigned long *_auxv __attribute__((weak)); +int main(int argc, char *argv[], char **envp);
This will lead to conflicting declarations if the users use a different signature. I'm not (yet?) sure how to work around this.
Ah yes, I forgot this critical case, people may use something like:
int main(void) int main(int argc, char *argv[])
[..]
I thought about this general problem and it turns out that there is nothing that any libc can do to distinguish these special cases. So it has to be handled in the compiler and we do not have to care.
Thomas