Per guidelines, all statements should have braces around them. We do not
have a CI check for this, so a few went in unnoticed.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Within the past few days, an update to the Ubuntu 18.04 toolchain has
begun emitting code sections during link that are messing with our
stub generation. They are appearing in the 32 bit stub link despite
not being defined in the single object file, and (worse) being
included in the output segment (i.e. at the start of the bootloader
entry point!) despite not being specifically included by the linker
script. I don't understand this behavior at all, and it appears to be
directly contrary to the way the linker is documented.
Marc Herbert discovered this was down to gcc being called with
--enable-default-pie, so -no-pie works to suppress this behavior and
restore the default. And it's correct: we aren't actually generating
a position independent executable, even if we don't understand why the
linker script is being disregarded (to include sections we don't
include). See discussion in the linked github issue.
Fixes#15877
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Update the files which contain no license information with the
'Apache-2.0' SPDX license identifier. Many source files in the tree are
missing licensing information, which makes it harder for compliance
tools to determine the correct license.
By default all files without license information are under the default
license of Zephyr, which is Apache version 2.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This macro is slated for complete removal, as it's not possible
on arches with an MPU stack guard to know the true buffer bounds
without also knowing the runtime state of its associated thread.
As removing this completely would be invasive to where we are
in the 1.14 release, demote to a private kernel Z_ API instead.
The current way that the macro is being used internally will
not cause any undue harm, we just don't want any external code
depending on it.
The final work to remove this (and overhaul stack specification in
general) will take place in 1.15 in the context of #14269Fixes: #14766
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Rename reserved function names in arch/ subdirectory. The Python
script gen_priv_stacks.py was updated to follow the 'z_' prefix
naming.
Signed-off-by: Patrik Flykt <patrik.flykt@intel.com>
MISRA defines a serie of essential types, boolean, signed/unsigned
integers, float, ... and operations must respect these essential types.
MISRA-C rule 10.1
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
The shared page is inherently used in multiprocessor contexts where
the compiler optimizer can trip us up (specifically, a spin on
num_active_pus was being hoisted out of the loop on some gcc's). Put
the volatile declartion into the struct pointer itself instead of
relying on the code to get it right.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Currently thread abort doesn't work if a thread is currently scheduled
on a different CPU, because we have no way of delivering an interrupt
to the other CPU to force the issue. This patch adds a simple
framework for an architecture to provide such an IPI, implements it
for x86_64, and uses it to implement a spin loop in abort for the case
where a thread is currently scheduled elsewhere.
On SMP architectures (xtensa) where no such IPI is implemented, we
fall back to waiting on an arbitrary interrupt to occur. This "works"
for typical code (and all current tests), but of course it cannot be
guaranteed on such an architecture that k_thread_abort() will return
in finite time (e.g. the other thread on the other CPU might have
taken a spinlock and entered an infinite loop, so it will never
receive an interrupt to terminate itself)!
On non-SMP architectures this patch changes no code paths at all.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Before we're initialized and can use proper synchronization, the CPU
initialization path spins on the thread entry function to be non-null.
But the data wasn't tagged volatile, and with gcc 8.2.1 (but not
6.2.0) the optimizer was hoisting the reads to SMP init would spin
forever.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The previous scheme where the xuk layer would call out to the to
"fetch" the stack for a SMP CPU at startup was sorta weird, and an
impedance mismatch with Zephyr which has a "start this CPU" call
instead. It also got broken when x86_64 started launching CPUs
(correctly) on their interrupt stacks instead of a temporary area;
they weren't ready yet when xuk initialization was happening and the
system would deadlock waiting for code that can't run yet to provide a
stack.
Note that this preserves the somewhat quirky behavior that Zephyr's
CPU numbering is just the order in which the SMP CPUs emerge from
initialization and not a hardware ID.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When this code was written, there was no "stack frame" struct defined.
There is now, so use that for clarity and concision. Also remove an
obvious comment (I mean, duh, we can put any segment selectors in
those fields we want).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There was a spot where the early boot code was logging using %p to
emit an integer, and Coverity doesn't like that. Fixes#14420 and
Fixes#14418
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Update reserved function names starting with one underscore, replacing
them as follows:
'_k_' with 'z_'
'_K_' with 'Z_'
'_handler_' with 'z_handl_'
'_Cstart' with 'z_cstart'
'_Swap' with 'z_swap'
This renaming is done on both global and those static function names
in kernel/include and include/. Other static function names in kernel/
are renamed by removing the leading underscore. Other function names
not starting with any prefix listed above are renamed starting with
a 'z_' or 'Z_' prefix.
Function names starting with two or three leading underscores are not
automatcally renamed since these names will collide with the variants
with two or three leading underscores.
Various generator scripts have also been updated as well as perf,
linker and usb files. These are
drivers/serial/uart_handlers.c
include/linker/kobject-text.ld
kernel/include/syscall_handler.h
scripts/gen_kobject_list.py
scripts/gen_syscall_header.py
Signed-off-by: Patrik Flykt <patrik.flykt@intel.com>
The lowest level of the x86_64 bit port supports the full 64 bit ABI
just fine, but Zephyr does not (yet) and builds under the x32 ABI
instead. The xuk layer can be built with or without the -mx32 switch,
and it had a configurable in a header to tell it what it was. At some
point during development I swept through and turned all those tunables
into kconfigs, but this one wasn't used by zephyr and so it got the
CONFIG_* rename but never had an entry added to a Kconfig file to
match it, and eventually got picked up by Ulf's unused symbol
detector.
Rename back. It will probably become a kconfig again someday when we
need it. Fixes#14059.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There is an effort underway to make most of the Zephyr build script's
reentrant. Meaning, the build scripts can be executed multiple times
during the same CMake invocation.
Reentrancy enables several use-cases, the motivating one is the
ability to build several Zephyr executables, or images, for instance a
bootloader and an application.
For build scripts to be reentrant they cannot be directly referencing
global variables, like target names, but must instead reference
variables, which can vary from entry to entry.
Therefore, in this patch, we replace global targets with variables.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
This patch adds a x86_64 architecture and qemu_x86_64 board to Zephyr.
Only the basic architecture support needed to run 64 bit code is
added; no drivers are added, though a low-level console exists and is
wired to printk().
The support is built on top of a "X86 underkernel" layer, which can be
built in isolation as a unit test on a Linux host.
Limitations:
+ Right now the SDK lacks an x86_64 toolchain. The build will fall
back to a host toolchain if it finds no cross compiler defined,
which is tested to work on gcc 8.2.1 right now.
+ No x87/SSE/AVX usage is allowed. This is a stronger limitation than
other architectures where the instructions work from one thread even
if the context switch code doesn't support it. We are passing
-no-sse to prevent gcc from automatically generating SSE
instructions for non-floating-point purposes, which has the side
effect of changing the ABI. Future work to handle the FPU registers
will need to be combined with an "application" ABI distinct from the
kernel one (or just to require USERSPACE).
+ Paging is enabled (it has to be in long mode), but is a 1:1 mapping
of all memory. No MMU/USERSPACE support yet.
+ We are building with -mno-red-zone for stack size reasons, but this
is a valuable optimization. Enabling it requires automatic stack
switching, which requires a TSS, which means it has to happen after
MMU support.
+ The OS runs in 64 bit mode, but for compatibility reasons is
compiled to the 32 bit "X32" ABI. So while the full 64 bit
registers and instruction set are available, C pointers are 32 bits
long and Zephyr is constrained to run in the bottom 4G of memory.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Anas Nashif