This abstracts the interface for generation of the strip command
line, by naming the desired actions instead of directly setting the
command parameters, which then opens up for other binary tool sets
which may require different arguments to achieve the desired result.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
This abstracts the interface for generation of the readelf command
line, by naming the desired actions instead of directly setting the
command parameters, which then opens up for other binary tool sets
which may require different arguments to achieve the desired result.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
This abstracts the interface for generation of the objdump command
line, by naming the desired actions instead of directly setting the
command parameters, which then opens up for other binary tool sets
which may require different arguments to achieve the desired result.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
This abstracts the interface for generation of the objcopy command
line, by naming the desired actions instead of directly setting the
command parameters, which then opens up for other binary tool sets
which may require different arguments to achieve the desired result.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
The method for getting a memory usage report printed during build, is
based on a GNU linker (ld) option flag, and thus is not necessarily
supported by other toolchain binary tools.
The introduced cmake macro allows for a given toolchain to specify how
the memory usage report is to be generated, and whether the command for
generation, if any, is to be added to the post_build_commands and the
post_build_byproducts lists of the top level CMakeLists.txt
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
The macro, toolchain_cc_produce_debug_info, adds the compiler specific
flag for enabling the production of debugging information in the
toolchain native format.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
In order to make sure that the build works in folders that require a UTF
encoding, make sure that both CMake and the various Python scripts that
interact with each other on files use the same encoding, in this case
UTF-8.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
This script is looking for a hyperspecific error (mismatched padding
when linking into two simultaneous output sections) that bit us once,
in an era where the linker scripts were less unified. We haven't seen
it crop up since, and multiple platforms have changed the way they do
this anyway.
It's needless complexity. Junk it.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The zephyr_stdint.h file enforces Zephyr specific policies on the
compilation environment. Let's give compilers a chance to provide
definitions of their own via TOOLCHAIN_C_FLAGS prior the inclusion
of zephyr_stdint.h.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Compilers (at least gcc and clang) already provide definitions to
create standard types and their range. For example, __INT16_TYPE__ is
normally defined as a short to be used with the int16_t typedef, and
__INT16_MAX__ is defined as 32767. So it makes sense to rely on them
rather than hardcoding our own, especially for the fast types where
the compiler itself knows what basic type is best.
Using compiler provided definitions makes even more sense when dealing
with 64-bit targets where some types such as intptr_t and size_t must
have a different size and range. Those definitions are then adjusted
by the compiler directly.
However there are two cases for which we should override those
definitions:
* The __INT32_TYPE__ definition on 32-bit targets vary between an int
and a long int depending on the architecture and configuration.
Notably, all compilers shipped with the Zephyr SDK, except for the
i586-zephyr-elfiamcu variant, define __INT32_TYPE__ to a long int.
Whereas, all Linux configurations for gcc, both 32-bit and 64-bit,
always define __INT32_TYPE__ as an int. Having variability here is
not welcome as pointers to a long int and to an int are not deemed
compatible by the compiler, and printing an int32_t defined with a
long using %d makes the compiler to complain, even if they're the
same size on 32-bit targets. Given that an int is always 32 bits
on all targets we might care about, and given that Zephyr hardcoded
int32_t to an int before, then we just redefine __INT32_TYPE__ and
derrivatives to an int to keep the peace in the code.
* The confusion also exists with __INTPTR_TYPE__. Looking again at the
Zephyr SDK, it is defined as an int, even even when __INT32_TYPE__ is
initially a long int. One notable exception is i586-zephyr-elf where
__INTPTR_TYPE__ is a long int even when using -m32. On 64-bit targets
this is always a long int. So let's redefine __INTPTR_TYPE__ to always
be a long int on Zephyr which simplifies the code, works for both
32-bit and 64-bit targets, and mimics what the Linux kernel does.
Only a few print format strings needed adjustment.
In those two cases, there is a safeguard to ensure the type we're
enforcing has the right size and fail the build otherwise.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Found a few annoying typos and figured I better run script and
fix anything it can find, here are the results...
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
TEST configurations don't need to be warned that they're using test
techniques with some side-effects.
On a typical sanitycheck invocation, this warning is one of the only two
that appears in most test runs. In other words this commit gets rid of
half of the entire grep -ri '[[:blank:]]warn' noise that obscures any
work-in-progress warnings or platform specific warnings in the
logs (typically: device tree warnings).
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
In commit 28a5657f1f we stopped ZEPHYR_BASE from leaking into
__FILE__ and other macros. This works great for apps inside ZEPHYR_BASE
but does nothing for apps outside ZEPHYR_BASE.
-fmacro-prefix-map=${CMAKE_SOURCE_DIR}=CMAKE_SOURCE_DIR does it.
To avoid collisions and for consistency change:
-fmacro-prefix-map=${ZEPHYR_BASE}=.
to:
-fmacro-prefix-map=${ZEPHYR_BASE}=ZEPHYR_BASE
Quickest test/demo:
- Copy samples/hello_word/ to ~/home_world/
- Add "%s", __FILE__ to printf in ~/home_world/src/main.c
cmake -B build -S ~/home_world/ -DBOARD=qemu_x86
make -C build run
Before:
~/home_world/src/main.c says Hello World! qemu_x86
After:
CMAKE_SOURCE_DIR/src/main.c says Hello World! qemu_x86
objdump -h $(find build -name *.c.obj) | grep noinit
9 .noinit."ZEPHYR_BASE/kernel/system_work_q.c".0 0000
17 .noinit."ZEPHYR_BASE/kernel/init.c".2 00000100 000
18 .noinit."ZEPHYR_BASE/kernel/init.c".1 00000400 000
19 .noinit."ZEPHYR_BASE/kernel/init.c".3 00000800 000
16 .noinit."ZEPHYR_BASE/kernel/mailbox.c".2 00000348
18 .noinit."ZEPHYR_BASE/kernel/mailbox.c".1 00000028
20 .noinit."ZEPHYR_BASE/kernel/pipes.c".2 00000280 00
22 .noinit."ZEPHYR_BASE/kernel/pipes.c".1 00000028 00
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
The different linker steps are all hardcoded to the output filename
"zephyr.map" and only the last one survives.
Un-harcode.
This removes some confusion when trying to follow who builds
what/when/how and it stops destroying intermediate linking information
useful when tracing/debugging new features or issues in the build.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
The macro obtains the toolchain specific flag and value for
setting of the requested c standard.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
Final step of linker abstraction:
* Abstract zephyr_lnk by including it in toolchain_ld_link_elf.
* Abstract relevant uses of target_link_libraries.
* Introduce toolchain_ld_force_undefined_symbols.
No functional change expected.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting non-intrusive porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
The macro is intended to abstract the -fno-common compiler option
which controls the placement of uninitialized global variables. The
macro leaves it up to the toolchain to define the option.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
The macro is intended to abstract the -imacros compiler option for
inclusion of the autoconf.h header file. The abstraction allows for a
given toolchain to decide how the inclusion of the header file is to
be done.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
The macro is intended to abstract the -ffreestanding compiler option
which tells the compiler that this is a bare metal env. The option is
compiler and thus toolchain specific, but this macro leaves it up to
the toolchain to decide the value of the option.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
cmake has a number of issues dealing with symbolic links:
https://gitlab.kitware.com/cmake/cmake/issues/16228
One of them can cause cmake to rewrite the -S input from the user and
CMAKE_SOURCE_DIR to unexpectedly include symbolic links:
https://cmake.org/pipermail/cmake/2019-May/thread.html#69496
Catch this corner case and warn about subtle issues like breaking
-fmacro-prefix-map=${ZEPHYR_BASE}=
Sample warning message:
CMake Warning at ../../CMakeLists.txt:30 (message):
ZEPHYR_BASE doesn't match CMAKE_CURRENT_SOURCE_DIR
ZEPHYR_BASE = ~/zephyrproject/zephyr
PWD = ~/westsymlink/zephyr/samples/hello_world
CMAKE_CURRENT_SOURCE_DIR = ~/westsymlink/zephyr
You may be using a mix of symbolic links and real paths which causes
subtle and hard to debug CMake issues.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
As we start adding more modules, all of them end up in
${CMAKE_BINARY_DIR}/ and this is getting too busy. We have a module
directory created for each module and the interesting build data is
getting lost in the crowd.
Move all module into ${CMAKE_BINARY_DIR}/modules to and keep them under
one directory.
Future enhancement: maintain the same structure of the modules as
checked out by west.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Introducing the macro toolchain_cc_warning_error_implicit_int which,
abstracts the implicit_int error flag thus leaving it to the toolchain
to decide whether this flag is needed or not.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
The macros are named toolchain_cc_warning_error_misra_sane and
toolchain_cc_cpp_warning_error_misra_sane
These macros provide toolchain specific flag(s) relating to the MISRA
SANE configuration option.
The macros will place the flag(s) in a variable provided by caller,
which can then add to zephyr compile options.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
- Make the 'C++ Standard' choice depend on CPLUSPLUS, so that it only
shows up when C++ support is enabled.
Also check that CPLUSPLUS is enabled before checking the standard in
the top-level CMakeLists.txt, to avoid triggering an assert.
- The 'C++ Options' menu now contains just CPLUSPLUS and its indented
children. Remove one menu level by removing the menu and turning
CPLUSPLUS into a 'menuconfig' symbol. Also change the prompt from
"Enable C++ support for the application" to just "C++ support for the
application", to make it consistent with e.g. "Logging".
- Factor out the common CPLUSPLUS dependency with an 'if CPLUSPLUS'.
- Order symbol properties more consistently with other Kconfig files,
with the prompt at the top, etc.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
This is placeholder for extended warning flags, likely to change between
toolchains.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
This is placeholder for base warning flags, common to most toolchains.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
The introduced macros are placeholders for the cmake parameter warning
level.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
No functional change expected.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting non-intrusive porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
* KERNEL_ELF was easily confused with KERNEL_ELF_NAME and KERNEL_NAME.
* kernel_elf as the name of the binary indicates it somehow only
contains the kernel, which is not correct.
Rename to zephyr_final as this is the reality: Zephyr elf has been
linked again (a number of times) due to generated kernel files.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
Move PROPERTY_LINKER_SCRIPT_DEFINES to toolchain_ld_base.
No functional change expected.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting non-intrusive porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
No functional change expected.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting non-intrusive porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
While configure_linker_script() may be useful for other linkers, it
currently only aimed at GNU ld. To really be useful among different
linkers, we would need to abstract its usage of the C preprocessor.
We can do this later, if needed.
No functional change expected.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
Rather than associating defines within the function, let the call sites
themselves pick the appropriate define. Add new argument for this.
This also permits us to remove regex matching.
No functional change expected.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
Reduce the amount of {pre,post}fixing magic: I.e. let it be clearer at
call sites that "linker.cmd" is a file, rather than having to know that
"linker" will be postfixed with ".cmd" internally.
Change argument name to linker_script_gen, to better indicate that we
are producing a generated file.
No functional change expected.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
Now that we avoid the two-step procedure, we can simplify the name of
the construct_add_custom_command_for_linker_pass macro.
Move description comment up to head of definition, making the purpose
clearer.
No functional change expected.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
Change construct_add_custom_command_for_linker_pass from function into
macro. The purpose of the function was to set the output variable to a
string that would be fed to add_custom_command. This meant all use
required a two-step procedure and an intermediate
variable (custom_command).
The environmental leakage from a macro in this case is small, so let's
just simplify to a macro and avoid the two-step.
No functional change expected.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
Full grep reveal ALIGN_SIZING_DEP is only mentioned in cmake, where
it is never assigned a value.
No functional change expected.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
No functional change expected.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting non-intrusive porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
No functional change expected.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting non-intrusive porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
Move GNU ld linker specific flags related to orphan handling into
toolchain_ld_baremetal().
No functional change expected.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting non-intrusive porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
Move --gc-sections flag to toolchain_ld_base()
Move --build-id=none flag to toolchain_ld_base()
No functional change expected.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting non-intrusive porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
The intent of toolchain_ld_baremetal() is to collect the flags belonging
to non-hosted (i.e. POSIX-based) targets.
No functional change expected.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting non-intrusive porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
* LINKERFLAGPREFIX's value is GNU ld specific, and
* LINKERFLAGPREFIX is not a convention always honored by all linkers.
Thus we shall not set it from the common root CMakeList.txt.
So we move to linker/ld/target.cmake.
No functional change expected.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting non-intrusive porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
When linking, clang doesn't pick -T for some reason and complains,
while -Wl,-T works for both, gcc and clang.
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
toolchain_ld_base() represents flags that are fundamental to linking or
otherwise does not belong in any further specified linker flag category.
No functional change expected.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting non-intrusive porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
toolchain_cc_nostdinc does not only obtain flags (to be placed in a
variable), it obtains and applies them.
No functional change expected.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
