Messages in this thread | | | From | Zhangjin Wu <> | Subject | Re: [PATCH v1 03/11] tools/nolibc: include crt.h before arch.h | Date | Mon, 3 Jul 2023 22:55:00 +0800 |
| |
> 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
> > [..]
| |