Add a '--dts-out <file>' flag to gen_defines.py that saves the final
devicetree to <file>, in DTS format, using the new EDT.dts_source
attribute.
Handy to have available as a debugging aid. Unused otherwise.
Also write a dummy <BOARD>.dts_compiled file that tells people to look
at zephyr.dts, for people that might be used to that file. It was
removed in commit 8d8b06978c ("dts: Remove generation of
<BOARD>.dts_compiled").
Fixes: #22272
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Introduce HAS_NEWLIB_LIBC_NANO Kconfig option that the toolchain
specific Kconfig (gnuarmemb & zephyr 0.11) can select to convey that the
feature is supported.
This removes the need to if protect the NEWLIB_LIBC_NANO Kconfig with:
if "$(ZEPHYR_TOOLCHAIN_VARIANT)" = "gnuarmemb"
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Allow a given toolchain to specify Kconfig options that might be
relevant to a feature available in that toolchain.
For example, the ARM embedded GNU toolchain supports two variants of
newlib and you select the smaller one via a spec file. We can use a
Kconfig option like HAS_NEWLIB_LIBC_NANO to convey that this feature is
supported by that toolchain.
We look for the toolchain Kconfig in ${TOOLCHAIN_KCONFIG_DIR}/Kconfig,
and default TOOLCHAIN_KCONFIG_DIR to:
${TOOLCHAIN_ROOT}/cmake/toolchain/${ZEPHYR_TOOLCHAIN_VARIANT})
toolchain specific cmake files can override the default if needed.
Additionally tweaked the zephyr/generic.cmake to use
${CMAKE_CURRENT_LIST_DIR} to reduce some duplication.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
dtc is only used for static analysis (producing warnings) of the
DeviceTree sources. This means that valid Zephyr firmware can sanely
be built without it.
For some users, for instance Windows users that are not permitted to
use Chocolatey, installing dtc is problematic and installing it is not
worth the DT warnings that it provides.
To make using Zephyr easier for these users we make using DTC
recommended and opt-out, instead of mandatory.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Add an opt-in feature that will generate a Makefile with build
variables like CC, and KBUILD_CFLAGS for consumption by third-party
Make-based build systems.
This emulates the 'outputexports' target that KBuild supported and is
supported for the same reasons that KBuild supported it. Easier
integration with third-party build systems.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
In zephyr_linker_sources().
This is done since the point of the location is to place things at given
offsets. This can only be done consistenly if the linker code is placed
into the _first_ section.
All uses of TEXT_START are replaced with ROM_START.
ROM_START is only supported in some arches, as some arches have several
custom sections before text. These don't currently have ROM_START or
TEXT_START available, but that could be added with a bit of refactoring
in their linker script.
No SORT_KEYs are changed.
This also fixes an error introduced when TEXT_START was added, where
TEXT_SECTION_OFFSET was applied to riscv's common linker.ld instead of
to openisa_rv32m1's specific linker.ld.
Signed-off-by: Øyvind Rønningstad <oyvind.ronningstad@nordicsemi.no>
There are some issues with the behavior when rerunning CMake in an
already initialized build directory:
1. The check for assignments to promptless symbols in configuration
fragments isn't run when reconfiguring, because it only runs if
zephyr/.config doesn't exist
2. As outlined in
https://github.com/zephyrproject-rtos/zephyr/issues/9573, you can
get into situations where zephyr/.config is invalid (e.g. due to
being outdated), but menuconfig/guiconfig can't be run to fix it
3. If kconfig.py fails while merging fragments during reconfiguration,
it will ignore the fragments during the next reconfiguration and use
the existing zephyr/.config instead, because the fragment checksum
is calculated and saved before running kconfig.py
(Footnote: The input configuration file(s) to kconfig.py can be either a
list of configuration fragments, when merging fragments, or just
zephyr/.config, if the merged configuration is up-to-date. The output
configuration file is always zephyr/.config.)
To fix the first two issues, explicitly tell kconfig.py when it's
dealing with handwritten configuration input (fragments), via a new
--handwritten-input-configs flag. This is more robust than checking
whether zephyr/.config exists, which was the old logic.
When dealing with handwritten input, there should be no assignments to
promptless symbols. Assignments to promptless symbols is expected in
zephyr/.config however, because it doubles as configuration output.
When running menuconfig/guiconfig, the input configuration is
zephyr/.config rather than configuration fragments, so this change also
makes sure that menuconfig can always be run as long as zephyr/.config
exists and is up-to-date.
To fix the last issue, only write the checksum for the configuration
fragments if kconfig.py succeeds (which means it wrote a
zephyr/.config).
Also improve naming a bit, add help texts for the command-line
parameters to kconfig.py, and simplify write_kconfig_filenames() by
moving logic into it.
Partial fix for
https://github.com/zephyrproject-rtos/zephyr/issues/9573, without the
part in #issuecomment-469701831. Can still run into issues when e.g.
when CMake files can't make sense of settings.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
To facilitate extending the generated reports without having to
patch this file, leverage generator-expression so that
dependencies can be added to the 'zephyr_property_target' target.
Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
generated_dts_board.h is pretty redundant and confusing as a name. Call
it devicetree.h instead.
dts.h would be another option, but DTS stands for "devicetree source"
and is the source code format, so it's a bit confusing too.
The replacement was done by grepping for 'generated_dts_board' and
'GENERATED_DTS_BOARD'.
Two build diagram and input-output SVG files were updated as well, along
with misc. documentation.
hal_ti, mcuboot, and ci-tools updates are included too, in the west.yml
update.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
The `zephyr_get_xxx` API for option fetching
enables prefix stripping. For some reason
the main API docs named it 'SKIP_PREFIX' instead.
Signed-off-by: Timor Gruber <timor.gruber@gmail.com>
Unused after the old devicescript were removed in commit c8c35f76ab
("scripts: dts: Remove deprecated extract_dts_includes.py script"). The
old scripts relied on parsing the output of 'dts -Odts', which replaces
e.g. phandle references. The new scripts parse the DTS files directly.
Keep running the dtc compiler just to catch any warnings/errors from it.
The edit to doc/guides/build/build-config-phase.svg is to remove the box
with '*.dts_compiled' in it (and the arrows to/from it). https://draw.io
can be used to edit it.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
This commit splits the 'locore' and 'main' memory regions into
separate executable images and specifies the 'locore' as the boot
kernel, in order to prevent the QEMU direct multiboot kernel loader
from overwriting the BIOS and option ROM areas located in between
the two memory regions.
The Zephyr x86-64 kernel image consists of two discontiguous load
memory regions: 'locore' at 0x8000 and 'main' at 0x100000, but the
QEMU treats these as single contiguous memory region starting at
0x8000 and ending at (0x100000 + MAIN_IMAGE_SIZE - 1).
This results in the direct multiboot kernel loader overwriting the
BIOS and option ROM areas as part of the kernel loading process, and
causes any writable system regions to be corrupted (e.g. KVMVAPIC ROM).
By splitting the two discontiguous memory regions into separate images
and specifying only the boot image (i.e. 'locore') as the '-kernel',
it is possible to work around the QEMU direct kernel loading design
limitation.
This workaround is required to support the QEMU v4.2.0 and above.
For more details, refer to the issue zephyrproject-rtos/sdk-ng#168.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Fix an issue with 'ZEPHYR_TOOLCHAIN_VARIANT=host' where CMAKE_C_FLAGS
was incorrectly assumed to be set.
This fixes#21614
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
The XCC toolchain may come with Clang front-end depending on
how it's built. Currently, the only SoC/board using XCC is
the intel_s1000_crb and its XCC toolchain comes with Clang
3.9.0 which has a lot better support for C99 and C++11 than
the portion based on GCC 4.2 (which does not even support
C++11). So this change attempts to use the Clang portion
instead of GCC if the Clang executable exists.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The undefined symbol option "-u" applies to linker so prefix
it with the linker prefix (usually "-Wl"). This fixes warnings
from LLVM/Clang about unknown arguments.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The current QEMU console configuration directly connects the console
serial port to the backend using '-serial' option.
This is less than ideal because only single console instance can be
connected to a backend and aggregation of multiple console outputs is
not possible (e.g. multiple console serial ports and semihosting
console to single console backend).
In order to solve this problem, single multiplexed chardev console
backend is declared and all consoles are connected to it.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
For application portability, it is required that feature activation
is made conditional in shield configuration. This way features remain
controlled on application side.
To enable this we need that list of user activated shield is made
available to Kconfig.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Xtensa requires building a new toolchain for a specific SoC.
By default xtools built Xtensa toolchains all have prefix of
xtensa-zephyr-elf. In order to distinguish different toolchains,
they are now placed in their own directories under their SoC
name. This allows us to have multiple Xtensa toolchains
targeting multiple SoCs.
The additional level in path name is introduced in SDK v0.11
and sdk-ng master.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Allows snippets to be placed in a predictable order into the linker
script. This is useful for data that must be placed at a particular
location.
Signed-off-by: Øyvind Rønningstad <oyvind.ronningstad@nordicsemi.no>
This adds the necessary bits to build the Xtensa HAL as
a module, and removes the bits to use the HAL built with
the Zephyr SDK.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
-Wold-style-definition is not a supported option for C++ builds. To
prevent it being passed:
* the list of compiler flags to be excluded from C++ builds is moved
to be toolchain-specific;
* -Wold-style-definition is added to that list for gcc and clang;
* -Wold-style-definition is moved from zephyr_compiler_options to
zephyr_cc_option so the option checking code is executed for it.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Zephyr currently requires Python 3.4 or later. The core Python team
declared version 3.4 hit End of Life (EOL) in March, so there's no
reason to continue to support it if that's causing a burden, which it
is.
This commit allows Zephyr's Python scripts to depend on features
present in version 3.6 or later.
This does skip support for a currently active version of Python:
- Python 3.5 is actively supported by the core Python devs until 09/2020
- Zephyr's 2.2 release, the first which could include this change, is
tentatively scheduled for 02/2020.
However, almost all supported platforms are either unaffected, or
their users can upgrade easily:
- Windows users who need to can upgrade Python with:
choco upgrade python
- macOS users who need to can upgrade Python with:
brew upgrade python3
- Red Hat Enterprise Linux users who need to upgrade can use
Software Collections (SCLs), e.g. as described here:
https://developers.redhat.com/blog/2018/08/13/install-python3-rhel/
- CentOS Linux users also have access to SCLs, as described here:
https://wiki.centos.org/AdditionalResources/Repositories/SCL
- Ubuntu's current long-term support (LTS) release (Bionic Beaver,
version 18.04) ships with Python 3.6. It and all later versions of
Ubuntu won't be affected by this change.
- Debian's current stable release (Buster, version 10) ships Python 3.7
and likewise won't be affected.
The impact of this change is therefore biggest for older versions of
Linux. In particular, these are impacted:
- Older Ubuntu LTS releases.
- Ubuntu 16.04 ships Python 3.5; it is still supported by Canonical.
- Ubuntu 14.04 ships Python 3.4, which is EOL. This Ubuntu version
is also no longer getting standard support from Canonical. Paying
customers are receiving security updates only.
https://wiki.ubuntu.com/Releases
- Older Debian versions.
- Debian 9 (stretch) ships Python 3.5 and is still a supported
Debian version.
- Debian 8 (jessie) ships Python 3.4, which is EOL. This Debian
version is no longer receiving mainline maintenance by the Debian
project. LTS updates are provided by interested community
volunteers only.
https://wiki.debian.org/LTS
Affected Linux users will no longer have a system Python 3 which works
"out of the box" with Zephyr after this change. Some ideas for these
users are:
- Use Zephyr v2.1 or v1.14 LTS, which are maintained and still
support Python 3.4
- Compile Python 3.6 or later from source and use it within a venv:
https://docs.python.org/3/library/venv.html
- Use something like https://github.com/pyenv/pyenv
Python 3.6 has compelling new features which make writing Zephyr's
scripts easier, and which it would be good to be able to rely upon.
This motivates moving from Python 3.4 to 3.6 instead of 3.5.
My personal killer 3.6 features motivating skipping 3.5 (YMMV):
- Windows console and file system encodings are UTF-8 (PEPs 528 and
529): Zephyr's scripts, and many utilities related to git, broadly
assume strings are UTF-8, so this is very helpful
- os.PathLike and the file system path protocol (PEP 519) allow
intermixing "smart" paths in pathlib with existing os.path based
code
- f-strings (PEP 0498) are a wonderful and efficient string
interpolation mechanism
- CPython dictionaries are insertion ordered as an implementation
detail starting with 3.6, which in practice helps with
reproducibility (and *all* Python implementations have insertion
ordered dicts starting with 3.7)
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
To detect where the cache directory has been located we have been
checking if $HOME is writable, and if it is assuming that $HOME/.cache
must be writable as well.
This is broken in environments where $HOME is owned by users and
$HOME/.cache is owned by admin. To fix this we check $HOME/.cache for
write-ability instead.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
The EXTRA_CPPFLAGS is applied via zephyr_compile_definitions()
instead of zephyr_compile_options(), which makes all specified
options as macros. So fix it.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
We do compiler flag compatibility tests to be able to support many
different toolchains and flags in a scalable way. But the test is not
perfect and in these situations we we will need to hardcode whether a
flag is compatible or not.
To support this we have zephyr_compiler_check first check if the flag
is covered by a hardcoded test before testing it.
Currently the only hardcoded compatibilty is that -Werror=implicit-int
is not supported for CXX.
This fixes#21229
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Change the DTS preprocessor working directory from the binary
directory to the application directory.
This is done so that the user can specify
-DDTC_OVERLAY_FILE=overlay.dts with a relative path from the
application directory as is possible for CONF_FILE, and as is
reasonably expected to be possible by users.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
We now use EDTS and gen_defines.py to generate DTS defines. We
deprecated the old script and defines several releases ago, so lets now
remove them.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Basic tool to help checking Kconfig options against a list of
hardening preferences.
This tool is available as a kconfig target, so to run it:
make/ninja hardenconfig
[Flavio Ceolin: Simplify logic and fix python lint issues]
Signed-off-by: Lauren Murphy <lauren.murphy@intel.com>
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
The -Og (optimise for debugging) flag is only available for GCC 4.8.0
and above, and specifying it for a GCC version lower than 4.8.0 will
result in a compilation error.
This commit adds a check for compiler -Og optimisation flag support and
a fallback to -O0 (disable optimisation) when -Og flag is unsupported.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
When generating the dependency file for DTS (${BOARD}.dts.pre.d),
some toolchains would use the source file for the file name stem.
So, the resulting dependency file is empty_file.d instead of one
with the board name. Fix this by passing -MF to explicitly tell
the compiler the name of the dependency file.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Renode 1.8 introduced a behaviour change in which it automatically
launches the telnet monitor on the TCP port 1234 by default.
In order to prevent sanitycheck failures from multiple renode instances
attempting to listen on the TCP port 1234 simultaneously, this commit
disables renode telnet monitor by specifying '--port -2' (a negative
number lower than -1 is required to disable telnet monitor because of
the way renode command line parser is implemented).
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
We need this information in the cache now that we're not allowed to
parse generated_dts_board.conf from Python code after build time.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This adds support for Zephyr SDK 0.11.* is based on the 0.10 support
with the following changes:
Handle how xtensa toolchains for given targets are organized in SDK
0.11.x. They have their own directories per specific xtensa SoC.
The x86_64 toolchain in the SDK has been updated to build for 32-bit
targets (as it has 32-bit soft float libraries). Use this toolchain for
all x86 builds.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The toolchain_ld_cpp macro currently uses zephyr_ld_options function
to link libstdc++, instead of zephyr_link_libraries which is actually
intended for this purpose.
This commit replaces the usage of zephyr_ld_options with
zephyr_link_libraries as the former may erroneously filter out
-lstdc++ and the latter ensures that this linker flag is
unconditionally forwarded to the linker.
For more details, refer to the issue #20406.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit refactors kernel and arch headers to establish a boundary
between private and public interface headers.
The refactoring strategy used in this commit is detailed in the issue
This commit introduces the following major changes:
1. Establish a clear boundary between private and public headers by
removing "kernel/include" and "arch/*/include" from the global
include paths. Ideally, only kernel/ and arch/*/ source files should
reference the headers in these directories. If these headers must be
used by a component, these include paths shall be manually added to
the CMakeLists.txt file of the component. This is intended to
discourage applications from including private kernel and arch
headers either knowingly and unknowingly.
- kernel/include/ (PRIVATE)
This directory contains the private headers that provide private
kernel definitions which should not be visible outside the kernel
and arch source code. All public kernel definitions must be added
to an appropriate header located under include/.
- arch/*/include/ (PRIVATE)
This directory contains the private headers that provide private
architecture-specific definitions which should not be visible
outside the arch and kernel source code. All public architecture-
specific definitions must be added to an appropriate header located
under include/arch/*/.
- include/ AND include/sys/ (PUBLIC)
This directory contains the public headers that provide public
kernel definitions which can be referenced by both kernel and
application code.
- include/arch/*/ (PUBLIC)
This directory contains the public headers that provide public
architecture-specific definitions which can be referenced by both
kernel and application code.
2. Split arch_interface.h into "kernel-to-arch interface" and "public
arch interface" divisions.
- kernel/include/kernel_arch_interface.h
* provides private "kernel-to-arch interface" definition.
* includes arch/*/include/kernel_arch_func.h to ensure that the
interface function implementations are always available.
* includes sys/arch_interface.h so that public arch interface
definitions are automatically included when including this file.
- arch/*/include/kernel_arch_func.h
* provides architecture-specific "kernel-to-arch interface"
implementation.
* only the functions that will be used in kernel and arch source
files are defined here.
- include/sys/arch_interface.h
* provides "public arch interface" definition.
* includes include/arch/arch_inlines.h to ensure that the
architecture-specific public inline interface function
implementations are always available.
- include/arch/arch_inlines.h
* includes architecture-specific arch_inlines.h in
include/arch/*/arch_inline.h.
- include/arch/*/arch_inline.h
* provides architecture-specific "public arch interface" inline
function implementation.
* supersedes include/sys/arch_inline.h.
3. Refactor kernel and the existing architecture implementations.
- Remove circular dependency of kernel and arch headers. The
following general rules should be observed:
* Never include any private headers from public headers
* Never include kernel_internal.h in kernel_arch_data.h
* Always include kernel_arch_data.h from kernel_arch_func.h
* Never include kernel.h from kernel_struct.h either directly or
indirectly. Only add the kernel structures that must be referenced
from public arch headers in this file.
- Relocate syscall_handler.h to include/ so it can be used in the
public code. This is necessary because many user-mode public codes
reference the functions defined in this header.
- Relocate kernel_arch_thread.h to include/arch/*/thread.h. This is
necessary to provide architecture-specific thread definition for
'struct k_thread' in kernel.h.
- Remove any private header dependencies from public headers using
the following methods:
* If dependency is not required, simply omit
* If dependency is required,
- Relocate a portion of the required dependencies from the
private header to an appropriate public header OR
- Relocate the required private header to make it public.
This commit supersedes #20047, addresses #19666, and fixes#3056.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Commit 28a5657f1f and f67dcdbdf8 stopped ZEPHYR_BASE and
CMAKE_SOURCE_DIR from leaking into __FILE__ and other macros.
WEST_TOPDIR was still missing. Add it now that the new 'west topdir'
command has been implemented in
https://github.com/zephyrproject-rtos/west/pull/311
If the west version is too old then do nothing; same as before.
Any ASSERT in a zephyr module outside ZEPHYR_BASE is enough to test
this. One example:
$ZEPHYR_BASE/sanitycheck -T $ZEPHYR_BASE/tests/posix/fs/ -p qemu_x86 -v
readelf --string-dump=.rodata.disk_status.str1.1 {} \
$(find sanity-out -name zfs_diskio.c.obj | head -n 1)
String dump of section '.rodata.disk_status.str1.1':
[ 0] WEST_TOPDIR/modules/fs/fatfs/zfs_diskio.c
[ 2a] pdrv < ((long) (((int) sizeof(char[1 - 2 * !(!__built....
[ de] ASSERTION FAIL [%s] @ %s:%d^J
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
If duplicates gets passed to scripts/dts/gen_defines.py, the bindings in
those directories will be loaded twice and actually get in conflict with
itself.
Signed-off-by: Tobias Svehagen <tobias.svehagen@gmail.com>
Speed up CMake by 100ms by importing west instead of invoking it as an
executable.
There is significant overhead in invoking west as a script via
pip. The exact reason why is not clear.
Also, simplify the version output parsing as we get the version in a
more machine-readable form now.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
This commit allows a more dynamic approach for specifying that a zephyr
library must be placed in a dedicated app memomory partition.
This is still done by defining the partition in code using
K_APPMEM_PARTITION_DEFINE, but now the zephyr library can be added to
the generation of partition table using zephyr_library_app_memory
instead of modifying the overall zephyr/CMakeLists.txt file.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Of the 1.7s or so that CMake spends in Configure-time there is 0.1s
spent to determine whether west can flash or not. This is significant
compared to the usefulness of flash-check.
AFAICT when installing west there is no longer a two-step procedure
where first a bootstrapper that can't flash is installed, and then a
proper west is installed, so the risk of having installed the
bootstrapper is no longer something we should spend 100ms testing for.
This patch removes the check, thereby speeding up CMake by 100ms.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Fixed a bug where python 3.8 was not detected on Windows.
Python 3.8 was released two weeks ago and any Windows user that
installs it will detect the wrong version.
Also add detection for 3.9 for future-proofing.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Move _LINKER and _ASMLANGUAGE to target.cmake because of how we pick the
linker script that might be used. This way regardless of how or where a
linker.ld gets included we will always set _LINKER & _ASMLANGUAGE (so
any header that needs check based on those defines they can,
specifically generated_dts_board.h)
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Since x86_64-zephyr-elf is a multi-lib toolchain, m32/m64
need to be specified for the compiler to return the correct
library path when queried (e.g. --print-libgcc-file-name).
This affects the compile check done by CMake. Without these
flags, the compiler returns incorrect toolchain path (e.g.
requiring 64-bit libraries but returning 32-bit library path).
This also affects compiler flag checks for "-lstdc++". Incorrect
library path results in error when checking for "-lstdc++", and
this flag will not be used for the build. This results in
undefined references when compiling C++ code.
This creates target_x86.cmake to add the necessary flags for
CMake to use. The target_x86_64.cmake is also created to
mirror the same change.
Also removing the -m32 flags for host-gcc since we are not
building x86 targets with the host-gcc compiler.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The target.cmake for xtools needs to be updated for changes in
sdk-ng repo. This is simply a copy from the target.cmake for
0.10 SDK.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
There are two set of code supporting x86_64: x86_64 using x32 ABI,
and x86 long mode, and this consolidates both into one x86_64
architecture and SoC supporting truly 64-bit mode.
() Removes the x86_64:x32 architecture and SoC, and replaces
them with the existing x86 long mode arch and SoC.
() Replace qemu_x86_64 with qemu_x86_long as qemu_x86_64.
() Updates samples and tests to remove reference to
qemu_x86_long.
() Renames CONFIG_X86_LONGMODE to CONFIG_X86_64.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Ulf Magnusson