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