The core kernel is built with the --no-whole-archive linker option.
For all the individual .o files which make up the kernel, if there
are no external references to symbols within these object files,
everything in the object file is dropped.
This has a subtle interaction with system call handlers. If an object
file has system call handlers inside it, and nothing else in the
object file is referenced, then the linker will prefer the weak
version of the handler in the generated syscall_dispatch.c. The
user will get an "unimplemented system call" error if the associated
system call for that handler is made.
Fix this by making a fake reference to the handler function at the
system call site. The address gets stored inside a special section
"hndlr_ref". This is enough to prevent the handlers from being
dropped, and the hndlr_ref section is itself dropped from the binary
from gc-sections; these references will not consume space.
Handlers for system calls that are never invoked anywhere will still be
dropped if nothing else in their containing C files is used, which is
a good thing. A future enhancement could be to split out all handlers
into individual object files, such that we can guarantee that any system
call that is not made somewhere in the application will have its handler
dropped. This will need to be extended to driver subsystems as well.
This won't be pretty but will ensure the tightest binary size.
Fixes#5184.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We need to enforce that if the implementation function is inlined,
and we are using a syscall declaration macro where a runtime check
is performed, that all memory access in the inlined implementation
function is done after the user context check is performed.
Fixes bad memory access issues observed due to the compiler fetching
member data from a kernel object when the calling context was in
user mode.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This is subject to the constraint that such system calls must have a
return value which is "u64_t" or "s64_t".
So far all the relevant kernel calls just have zero or one arguments,
we can later add more _syscall_ret64_invokeN() APIs as needed.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
__ZEPHYR_SUPERVISOR__ more accurately represents what this means: that
the code is intended for scenarios when the CPU is expected to be
running in supervisor (privileged) mode. This could be in the kernel or
in the application.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This used to exist because in earlier versions of the system call
interfaces, an "extern" declaration of the system call implementation
function would precede the real inline version of the implementation.
The compiler would not like this and would throw "static declaration
of ‘foo’ follows non-static declaration". So alternate macros were
needed which declare the implementation function as 'static inline'
instead of extern.
However, currently the inline version of these system call
implementations appear first, the K_SYSCALL_DECLARE() macros appear in
the header generated by gen_syscalls.py, which is always included at the
end of the header file. The compiler does not complain if a
static inline function is succeeded by an extern prototype of the
same function. This lets us simplify the generated system call
macros and just use __syscall everywhere.
The disassembly of this was checked on x86 to ensure that for
kernel-only or CONFIG_USERSPACE=n scenarios, everything is still being
inlined as expected.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
To define a system call, it's now sufficient to simply tag the inline
prototype with "__syscall" or "__syscall_inline" and include a special
generated header at the end of the header file.
The system call dispatch table and enumeration of system call IDs is now
automatically generated.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This header could be maintained by hand since there are no inputs
and it only changes if the generating script is modified, but given
the choice to maintain 800-ish lines of extremely repetitive C
preprocessor code, or 100-ish lines of Python, the choice is pretty
clear.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Anas Nashif