Commit Graph

4 Commits

Author SHA1 Message Date
Luca Burelli
78ae035f89 llext: fix link order for weak syscall symbols
The weak syscall symbols generated by gen_syscalls.py are currently
compiled in the LLEXT subsystem library, which is then linked among all
other Zephyr libraries in an unspecified order. This can cause the weak
symbols to override the actual syscall implementations, leading to
undefined behaviour.

To fix this, the currently generated file is split in two elements:

- syscall_exports_llext.c contains the EXPORT_SYMBOL directives for all
  syscalls. This part can be compiled with the LLEXT library and linked
  among all other Zephyr libraries, and ensures all syscalls symbols
  are preserved by the linker.

- syscall_weakdefs_llext.c contains the weak definitions for all syscalls.
  This file is compiled in a separate library that is linked last, so
  that the weak symbols are only used if no other implementation is
  available.

Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
2024-12-10 20:38:48 +01:00
Yong Cong Sin
3570408db5 build: namespace syscall sources to zephyr/
Namespace the `syscall_dispatch.c` & `syscall_export_llext.c`
to `zephyr/` as well

Signed-off-by: Yong Cong Sin <ycsin@meta.com>
2024-05-28 22:03:55 +02:00
Ederson de Souza
62b19ef65c syscalls: llext: Export z_impl symbols so they are available to kernel
commit 67bb6db3f8 ("syscall: Export all emitted syscalls, enabling
them for extensions") exports all emitted syscalls, however, it does
that only for the `z_mrsh` symbols, effectively only available for
userspace. If an extension running at kernel level tries to use a
syscall, it will fail to load.

This patch fixes that by exposing the `z_impl` symbols instead. However,
this is not as straightforward as the `z_mrsh` ones. As, in their
signatures, they can basically contain any type, it's not just a matter
of emitting `EXPORT_SYMBOL(z_impl_<syscall>)`, as the compiler will
complain about the undefined types. Here, there are a few approaches.

One of them is to have the `EXPORT_SYMBOL` being generated on the same
files where the syscall is implemented - injecting it there would allow
it to access all known symbols. But changing a lot of files is
undesirable, and it was one of the nice points of first patch.

Another one would be to reconstruct - or simply use the absolute path -
for the includes where the syscalls are defined. Reconstruct the paths
seems fragile and I'm not sure using absolute paths is portable.

Finally, the approach used in this patch is to declare, on a different
generated file, all `z_impl_` symbols as `void *` - after all, only the
address (and the name) to the function is relevant to EXPORT_SYMBOL. By
living in an compilation unit that doesn't include any header which
would expose any of the syscalls, there shouldn't be any conflicts. And
to account for the possibility that a syscall is not compiled - due
being configured out via Kconfig - all those symbols are also weak
aliases to a pointer to NULL. This file is then included in
`llext_export.c` (which should naturally not include any conflicting
header).

Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-03-26 19:31:56 -04:00
Guennadi Liakhovetski
69cdc32892 llext: export some symbols
Export some symbols for loadable modules. Also add an
EXPORT_SYSCALL() helper macro for exporting system calls by their
official names.

Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
2023-12-01 10:08:12 -05:00