[PATCH v1 03/11] tools/nolibc: include crt.h before arch.h

[Zhangjin Wu]

> 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

> > [..]