Hi, Thomas
> On 2023-07-10 17:26:43+0800, Zhangjin Wu wrote:
> > > On 2023-07-08 23:29:58+0800, Zhangjin Wu wrote:
[...]
>
> > > 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.
>
Thomas, seems we already have some testcases for argv, environ and auxv
currently:
run_syscall: chmod_argv0 <-- argv[0]
chdir_root <-- chdir(getenv("PWD"))
getpagesize <-- getauxval(AT_PAGESZ)
run_stdlib : getenv_TERM <-- getenv
> >
[...]
> > >
> >
> > Ok, welcome to discuss more in this thread:
> >
> > https://lore.kernel.org/lkml/20230710072340.10798-1-falcon@xxxxxxxxxxx/
> >
> > 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@xxxxxxxxxxx>
> > > > ---
> > > > 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.
>
Yes. for nolibc application is in one-file style, let's remove it.
> >
[...]
> > >
> > > 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.
Ok.
Thanks,
Zhangjin
>
> Thomas
