Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 3 Jul 2023 12:11:48 +0200
From:   Thomas =?utf-8?Q?Wei=C3=9Fschuh?= <thomas@t-8ch.de>
To:     Zhangjin Wu <falcon@tinylab.org>
Cc:     arnd@arndb.de, linux-kernel@vger.kernel.org,
        linux-kselftest@vger.kernel.org, linux-riscv@lists.infradead.org,
        w@1wt.eu
Subject: Re: [PATCH v1 03/11] tools/nolibc: include crt.h before arch.h
Message-ID: <8efbbfe5-1c3f-46df-9bc3-2ba62015f17e@t-8ch.de>
References: <e1cf8fd3-f8cd-4c3c-9f8c-24bbc0a7cde3@t-8ch.de>
 <20230703095832.493137-1-falcon@tinylab.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230703095832.493137-1-falcon@tinylab.org>
Precedence: bulk

On 2023-07-03 17:58:32+0800, Zhangjin Wu wrote:
> Hi, Thomas
> 
> > 
> > On 2023-06-29 02:54:35+0800, Zhangjin Wu wrote:
> > > The crt.h provides a new _start_c() function, which is required by the
> > > new assembly _start entry of arch-<ARCH>.h (included by arch.h), let's
> > > include crt.h before arch.h.
> > > 
> > > This '#include "crt.h"' doesn't let the new _start_c() work immediately,
> > > but it is a base of the coming patches to move most of the assembly
> > > _start operations to the _start_c() function for every supported
> > > architecture.
> > 
> > Why don't the arch-*.h files include this new header?
> > They are the users of the new symbol.
> >
> 
> I have tried so, but since crt.h itself is not architecture specific, add it
> before arch.h will avoid every new arch porting add the same thing again and
> again, currently, we only need to add once. I have even planned to move
> compiler.h out of arch-*.h, but not yet ;-)

While this saves a few lines of code in my opinion it hurts clarity to
rely on implicitly pre-included things.

> every new arch porting

That doesn't seem like a very frequent occurrence :-)

> And also, crt.h may require more features in the future, like init/fini
> support, it may be not only used by arch-*.h files.

Do you have a mechanism in mind that supports init/fini without needing
an ELF parser at runtime? I guess an ELF parser would make it a complete
no-go.

Also the value added by init/fini seems fairly limited for a statically
linked (tiny) application.

> [..]