Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Zhangjin Wu <falcon@tinylab.org>
To: thomas@t-8ch.de
Cc: arnd@arndb.de, falcon@tinylab.org, linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org, w@1wt.eu
Subject: Re: [PATCH v2 04/12] tools/nolibc: crt.h: add _start_c
Date: Tue, 11 Jul 2023 00:45:43 +0800	[thread overview]
Message-ID: <20230710164543.6284-1-falcon@tinylab.org> (raw)
In-Reply-To: <195a189b-b9d5-45a1-8901-c9bdb52da2f3@t-8ch.de>

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@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.
>

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

  reply	other threads:[~2023-07-10 16:46 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-08 15:25 [PATCH v2 00/12] tools/nolibc: shrink arch support Zhangjin Wu
2023-07-08 15:26 ` [PATCH v2 01/12] tools/nolibc: rename arch-<ARCH>.h to <ARCH>/arch.h Zhangjin Wu
2023-07-09  9:56   ` Willy Tarreau
2023-07-10  7:23     ` Zhangjin Wu
2023-07-10 15:51       ` Thomas Weißschuh
2023-07-11  7:41         ` Willy Tarreau
2023-07-11 16:38           ` Zhangjin Wu
2023-07-11 19:28             ` Willy Tarreau
2023-07-08 15:27 ` [PATCH v2 02/12] tools/nolibc: split arch.h to crt.h and sys.h Zhangjin Wu
2023-07-08 15:28 ` [PATCH v2 03/12] tools/nolibc: sys.h: remove the old sys_stat support Zhangjin Wu
2023-07-08 15:29 ` [PATCH v2 04/12] tools/nolibc: crt.h: add _start_c Zhangjin Wu
2023-07-09 18:49   ` Thomas Weißschuh
2023-07-09 21:00     ` Thomas Weißschuh
2023-07-10  9:26     ` Zhangjin Wu
2023-07-10 15:24       ` Thomas Weißschuh
2023-07-10 16:45         ` Zhangjin Wu [this message]
2023-07-08 15:31 ` [PATCH v2 05/12] tools/nolibc: arm/crt.h: shrink _start with _start_c Zhangjin Wu
2023-07-08 15:32 ` [PATCH v2 06/12] tools/nolibc: aarch64/crt.h: " Zhangjin Wu
2023-07-08 15:33 ` [PATCH v2 07/12] tools/nolibc: i386/crt.h: " Zhangjin Wu
2023-07-08 15:34 ` [PATCH v2 08/12] tools/nolibc: x86_64/crt.h: " Zhangjin Wu
2023-07-08 15:35 ` [PATCH v2 09/12] tools/nolibc: mips/crt.h: " Zhangjin Wu
2023-07-08 15:36 ` [PATCH v2 10/12] tools/nolibc: loongarch/crt.h: " Zhangjin Wu
2023-07-08 15:37 ` [PATCH v2 11/12] tools/nolibc: riscv/crt.h: " Zhangjin Wu
2023-07-08 15:38 ` [PATCH v2 12/12] tools/nolibc: s390/crt.h: " Zhangjin Wu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230710164543.6284-1-falcon@tinylab.org \
    --to=falcon@tinylab.org \
    --cc=arnd@arndb.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=thomas@t-8ch.de \
    --cc=w@1wt.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox