This patch adds an additional constraint to make sure that we only
do the application memory sizing if it is really necessary.
Signed-off-by: Andy Gross <andy.gross@linaro.org>
We want to support other toolchain not based on GCC, so the variable is
confusing, use ZEPHYR_TOOLCHAIN_VARIANT instead.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
To enable using application-defined sections in linker scripts, the
application source directory must be included in the search path when
running the preprocessor to generate linker scripts.
This prevents build failures when using any of the configuration options
CONFIG_CUSTOM_RODATA_LD, CONFIG_CUSTOM_RWDATA_LD and
CONFIG_CUSTOM_SECTIONS_LD.
Signed-off-by: Kristian Klomsten Skordal <kristian.skordal@nordicsemi.no>
In a scenario where a platform harbours multiple interrupts to the
extent the core cannot support it, an interrupt controller is added
as an additional level of interrupt. It typically combines several
sources of interrupt into one line that is then routed to the parent
controller.
Signed-off-by: Rajavardhan Gundi <rajavardhan.gundi@intel.com>
This patch adds the generation and incorporation of privileged stack
regions that are used by ARM user mode threads. This patch adds the
infrastructure for privileged stacks. Later patches will utilize the
generated stacks and helper functions.
Signed-off-by: Chunlin Han <chunlin.han@linaro.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
This patch adds application data section alignment constraints
to match the region definition requirements for ARM MPUs. Most MPUs
require a minimum of 32 bytes of alignment for any regions, but some
require power of two alignment to the size of a region.
This requires that the linker align the application data section to
the size of the section. This requires a linker pass to determine the
size. Once this is accomplished the correct value is added to a linker
include file that is utilized in subsequent linker operations.
Signed-off-by: Andy Gross <andy.gross@linaro.org>
This patch changes the way the custom linker function works. It uses
names instead of numbers to denote the name of the file and applies
the correct LINKER_PASS variable for the final linker pass.
Signed-off-by: Andy Gross <andy.gross@linaro.org>
We need to allocate extra memory region for the hash function
that the gperf generates. The linker will need to maintain
the same location counter between multiple linker stages. Reserving
memory will help in maintaing correct location counters between
multiple stages. The required memory varies with optimization level.
In order to keep the size of the compiled object consistent,
the kobject_hash.c is always compiled with -Os.
fixes#5226
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
This patch does several things, most notably it changes the semantics
of CONFIG_DEBUG. CONFIG_DEBUG continues to behave as a vaguely defined
"debug mode" that enables printf's, -Og, etc. but now the user may
choose to be in "debug mode" while using a different optimization
level than -Og.
Tp support this a new config is defined to enable -Og;
CONFIG_DEBUG_OPTIMIZATIONS.
Additionally CONFIG_SIZE_OPTIMIZATIONS is introduced to allow the user
to explicitly request optimizing for size instead of relying on
defaulting to it.
The three config's {NO,SIZE,DEBUG}_OPTIMIZATIONS are now organized in
a Kconfig choice to ensure that at most one can be enabled at a time.
Finally, selected users of CONFIG_DEBUG have been ported to use one of
the optimizations configs when it was clear from usage that the
intention was to behave differently when using a different
optimization level and not when in "debug mode".
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Added a new config option which lowers the compiler
optimizations to -O0 independently of other flags.
CONFIG_COVERAGE uses it now instead of having its own
choice in CMakeLists.txt
Fixes#5720
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
CMake's custom_command support is not great. It is technically
supported, but it is not easy to get it right.
As explained in "5. File-level dependencies of custom targets are not
propagated" from http://bit.ly/2GvwwEy. When a custom_command uses a
custom_target as input, the custom_command must DEPEND on both the
custom_target and the underlying file.
Longterm we need to do something more sofisticated to prevent these
issues from popping up. Like add some static analysis to detect badly
written CMake code or introduce an abstraction for custom commands
that is not affect by this issue.
This fixes#5881
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
This CMakeLists.txt is added via add_subdirectory() to the app's
CMakeLists.txt. If the app-CMakeLists.txt has install() rules and
wants to use them, setting CMAKE_SKIP_INSTALL_RULES to ON breaks
the 'make install' call.
Not setting this variable does not harm zephyr because zephyr does
not use install().
Signed-off-by: Patrick Boettcher <patrick.boettcher@posteo.de>
A fix for this issue is in progress, meanwhile warn the user that
they may be susceptible to this problem if they enable user mode on
an x86-based target that is not known to be immune.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Re-order the execution of the arch/ and subsys/ CMakeLists.txt code to
work around a manifestation of issue #6505. When OpenThread created an
External project in subsys, it did not have access to important
toolchain flags added in arch/.
Intuitively, subsystems might depends on how the ARCH is configured,
but the ARCH shouldn't depend on any subsystem.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Instead of accessing the environment variable ZEPHYR_BASE every time we
require accessing the source code root, use an intermediate variable
that has OS path separators correctly set to '/' to avoid issues on
Windows.
Note: This removes the ZEPHYR_SOURCE_DIR CMake variable. External
applications using that will need to change to use the new ZEPHYR_BASE
variable.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
A Zephyr library not having source files is usually due to a
misconfiguration and will lead to an obscure error message. But
imported Zephyr libraries don't have source files so we need to skip
the source file when a library is imported.
An imported Zephyr library is normally used to reference externally
built code, either prebuilt or recursively built through an external
build system.
This fixes#5497
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Depending on a path inside the Zephyr tree to determine if we are a test
does not scale. Also some samples were marked as TEST while they are
not, just to get some options defined for tests.
Idenitfying a test will be addressed in another patch introducing
CONFIG_TEST.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This fixes
https://github.com/zephyrproject-rtos/zephyr/issues/5010. CMake has a
simple parser that can parse C-like files to find header
dependencies. But the parser needs to know what the include
directories are to be able to follow #include pragmas.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Add a comment that explains what the -P flag does. The explanatory
comment is useful when you want to find the flag so you can comment it
out while debugging the link stage.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
The linker script places kernelspace and userspace archives in
different sections. But the linker script itself does not determine
what archives are in what space, that is done by CMake.
CMake passes the list of kernelspace archives to the linker script
through defines, like this:
-DNUM_KERNEL_OBJECT_FILES=3
-DKERNEL_OBJECT_FILE_0=path/to/archive_a.a
-DKERNEL_OBJECT_FILE_1=path/to/archive_b.a
-DKERNEL_OBJECT_FILE_2=path/to/archive_c.a
These paths are relative, and since Ninja and Make invoke the linker
with different "working directories"[0], the relative paths need to be
different. This patch rectifies the relative path when using Ninja.
This fixes#5343
[0] https://gitlab.kitware.com/cmake/cmake/issues/17448
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
When building for Ninja we were accidentally using the wrong depfile
in the second pass. This commit moves the LINKER_SCRIPT_DEP logic into
the custom command function so that it can be linker-pass-aware and
set the depfile appropriately.
This should fix an issue where Ninja reported:
ninja: error: expected depfile 'zephyr/linker.cmd.dep' to mention
'zephyr/linker_pass2.cmd', got 'zephyr/linker.cmd'
But this has not been reproduced. It has however been confirmed that a
dependency issue with linker_pass2.cmd has been fixed because ninja no
longer regenerates linker_pass2.cmd on every build like this:
$ ninja
[1/79] Generating always_rebuild
Building for board qemu_x86
[2/3] Generating linker_pass2.cmd
[3/3] Linking C executable zephyr/zephyr.elf
Now:
$ ninja
[1/78] Generating always_rebuild
Building for board qemu_x86
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Construct the custom command for preprocessing the linker script with
a function to avoid copy-paste errors between linker passes.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
per the gcov man page:
You should compile your code without optimization if you plan to use
gcov because the optimization, by combining some lines of code into one
function, may not give you as much information .
Fixes#5548
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The --print-memory-usage check was accidentally corrupting the
CMAKE_REQUIRED_FLAGS variable due to a variable de-referencing bug.
This was affecting app CMakeLists.txt code that was using
CMAKE_REQUIRED_FLAGS.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
With the native port we are able to generate coverage reports, add the
needed options to the compliler and add a kconfig option to enable this
on the supported architectures.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
To indicate the generated binary is executable on the host, add .exe
extension to the generated ELF file.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
All runner logic was implemented in qemu.cmake, remove the generic stuff
and make qemu.cmake qemu specific.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Right now we are hardcoded to only qemu, with the native port, we make
this more generic and support this in a plugin mode where a running has
its own cmake definitons implementing the various targets.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
A new arch (posix) which relies on pthreads to emulate the context
switching
A new soc for it (inf_clock) which emulates a CPU running at an
infinely high clock (so when the CPU is awaken it runs till completion
in 0 time)
A new board, which provides a trivial system tick timer and
irq generation.
Origin: Original
Fixes#1891
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
-Wl,--print-memory-usage is a relatively new LD feature (2015) and is
not supported by the espressif toolchain. Unfortunately the toolchain
compatibility test was broken as it was not using the flag when
linking.
The root cause lies in how we test LD compatibility and this same fix
must be applied again in e.g. target_ld_options().
This patch fixes
https://github.com/zephyrproject-rtos/zephyr/issues/5458
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Pass the --print-memory-usage to the linker on the first link if the
toolchain supports it.
Don't use this option with the second link because seeing it twice
could confuse users and using it on the second link would suppress it
when the first link has a ram/flash-usage issue.
Note that the memory regions are symbolic concepts defined by the
linker scripts and do not necessarily map directly to the real
physical address space. Take also note that some platforms do two
passes of the linker so the results do not match exactly to the final
elf file. See also rom_report, ram_report and
https://sourceware.org/binutils/docs/ld/MEMORY.html
This is particularly useful when the linker fails due to excessive
flash/ram usage. When a section does not fit into a memory region the
linker will exit with an error code and will state how big the
overflow was. But it doesn't state what the memory region size is, or
what memory regions exist, which is good to know when debugging
overflow issues.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
A very annoying usability issue is that the error message is very
cryptic when you create a zephyr library that doesn't have any source
files. Creating such a library is very easy to do, so we should have a
good error message for it.
It was also considered to allow empty libraries to exist, but this was
decided against as they show up in the build output and can confuse
the end user.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
When exporting flags to an external build system we need to deal with
the fact that we sometimes use generator expressions. Specifically, we
use generator expressions that look like this:
$<$<COMPILE_LANGUAGE:CXX>:-fno-exceptions>
This patch replaces the old API with a new one where users can ask for
compile options for specific languages, like this:
zephyr_get_compile_options_for_lang_as_string(CXX x)
The existing API would have either crashed or silently omitted flags
when a COMPILE_LANG generator expression was present.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
This commit fixes
https://github.com/zephyrproject-rtos/zephyr/issues/5008.
It does so by splitting up gen_syscalls.py into two scripts with a
json metadata file to communicate syscall metadata between them. The
parsing script parses header files from include/ and writes syscall
metadata to a file if the contents changed. The generation script
reads from the json file and generates syscall code.
The build system DAG now looks like this:
always_rebuild -> json -> syscalls -> offset.o
The script for generating json will do so only if the content changes,
this ensures that the entire DAG does not always do a full rebuild.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
This fixes https://github.com/zephyrproject-rtos/zephyr/issues/5186
The script that generates syscall_macros.h is moved from Configuration
time to build time. This allows us to express to the build system that
syscall_macros.h depends on the script that generates it.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Not all boards require the various binary formats zephyr generates. So
be selective based on the arch, SoC or board and only geenrate the
binaries actually needed.
Fixes#5009
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Introducing CMake is an important step in a larger effort to make
Zephyr easy to use for application developers working on different
platforms with different development environment needs.
Simplified, this change retains Kconfig as-is, and replaces all
Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild
offers is replaced by a set of CMake extentions. These extentions have
either provided simple one-to-one translations of KBuild features or
introduced new concepts that replace KBuild concepts.
This is a breaking change for existing test infrastructure and build
scripts that are maintained out-of-tree. But for FW itself, no porting
should be necessary.
For users that just want to continue their work with minimal
disruption the following should suffice:
Install CMake 3.8.2+
Port any out-of-tree Makefiles to CMake.
Learn the absolute minimum about the new command line interface:
$ cd samples/hello_world
$ mkdir build && cd build
$ cmake -DBOARD=nrf52_pca10040 ..
$ cd build
$ make
PR: zephyrproject-rtos#4692
docs: http://docs.zephyrproject.org/getting_started/getting_started.html
Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
Wayne Ren