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;
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, linux-riscv@lists.infradead.org,
        w@1wt.eu
Subject: Re: [PATCH v1 03/11] tools/nolibc: include crt.h before arch.h
Date:   Mon,  3 Jul 2023 22:55:00 +0800
Message-Id: <20230703145500.500460-1-falcon@tinylab.org>
In-Reply-To: <8efbbfe5-1c3f-46df-9bc3-2ba62015f17e@t-8ch.de>
References: <8efbbfe5-1c3f-46df-9bc3-2ba62015f17e@t-8ch.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Feedback-ID: bizesmtp:tinylab.org:qybglogicsvrgz:qybglogicsvrgz5a-1
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.
>

To be clearer, what about split the arch.h to sys_arch.h (my_syscall*)
and crt_arch.h? (_start part) and then, we can include crt_arch.h in
crt.h and at the same time, include sys_arch.h in sys.h, and at last
we need to create a <ARCH> directory for the them.

    crt.h:
        #include "crt_arch.h"

	_start_c ()

    sys.h:
        #include "sys_arch.h"

	sys_xxx()
	{
            my_syscall<N>(...)
	}

    crt_arch.h:

        #ifdef ARCH
        #include "<ARCH>/crt_arch.h"
	#endif

    sys_arch.h:

        #ifdef ARCH
        #inculde "<ARCH>/sys_arch.h"
	#endif

I just found musl uses such structure ;-)

> > every new arch porting
> 
> That doesn't seem like a very frequent occurrence :-)
>

Yes, it is not often.

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

I didn't really think about this yet ;-)

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

Yeah.

Thanks,
Zhangjin

> > [..]