[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220322172550.GL10306@1wt.eu>
Date: Tue, 22 Mar 2022 18:25:50 +0100
From: Willy Tarreau <w@....eu>
To: Nick Desaulniers <ndesaulniers@...gle.com>
Cc: Ammar Faizi <ammarfaizi2@...weeb.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Alviro Iskandar Setiawan <alviro.iskandar@...weeb.org>,
Nugraha <richiisei@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
GNU/Weeb Mailing List <gwml@...r.gnuweeb.org>,
llvm@...ts.linux.dev
Subject: Re: [RFC PATCH v2 2/8] tools/nolibc: Remove .global _start from the
entry point code
Hi Nick,
On Tue, Mar 22, 2022 at 10:09:18AM -0700, Nick Desaulniers wrote:
> On Tue, Mar 22, 2022 at 3:21 AM Ammar Faizi <ammarfaizi2@...weeb.org> wrote:
> >
> > Building with clang yields the following error:
> > ```
> > <inline asm>:3:1: error: _start changed binding to STB_GLOBAL
> > .global _start
> > ^
> > 1 error generated.
> > ```
> > Make sure only specify one between `.global _start` and `.weak _start`.
> > Removing `.global _start`.
>
> Reviewed-by: Nick Desaulniers <ndesaulniers@...gle.com>
>
> Yes, symbols should either be `.weak` or `.global`. The warning from
> Clang's integrated assembler is meant to flush out funny business.
>
> I assume there's a good reason _why_ _start is weak and not strong?
Yes, the issue appears when you start to build programs made of more than
one C file. That's why we have a few weak symbols here and there (others
like errno are static and the lack of inter-unit portability is assumed).
> Then again, I'm not familiar with nolibc.
No problem. The purpose is clearly *not* to implement a libc, but to have
something very lightweight that allows to compile trivial programs. A good
example of this is tools/testing/selftests/rcutorture/bin/mkinitrd.sh. I'm
personally using a tiny pre-init shell that I always package with my
kernels and that builds with them [1]. It will never do big things but
the balance between ease of use and coding effort is pretty good in my
experience. And I'm also careful not to make it complicated to use nor
to maintain, pragmatism is important and the effort should remain on the
program developer if some arbitration is needed.
Regards,
Willy
[1] https://github.com/formilux/flxutils/tree/master/init
Powered by blists - more mailing lists