zephyrproject-rtos / sdk-ng Goto Github PK

Zephyr SDK (Toolchains, Development Tools)

License: Apache License 2.0

Shell 0.03% BitBake 0.10% CMake 0.01% Python 0.01% C 99.79% C++ 0.06%

sdk-ng's Introduction

Zephyr SDK

The Zephyr Software Development Kit (SDK) includes the toolchains for all supported target architectures as well as the host tools, such as QEMU and OpenOCD, for testing and debugging the Zephyr RTOS.

The toolchains for the following target architectures are supported:

ARC (32-bit and 64-bit; ARCv1, ARCv2, ARCv3)
ARM (32-bit and 64-bit; ARMv6, ARMv7, ARMv8; A/R/M Profiles)
Microblaze (32-bit)
MIPS (32-bit and 64-bit)
Nios II
RISC-V (32-bit and 64-bit; RV32I, RV32E, RV64I)
SPARC (32-bit and 64-bit; SPARC V8, SPARC V9)
x86 (32-bit and 64-bit)
Xtensa (sample_controller, intel_ace15_mtpm, intel_tgl_adsp, nxp_imx_adsp, nxp_imx8m_adsp, nxp_imx8ulp_adsp, nxp_rt500_adsp, espressif_esp32, espressif_esp32s2, espressif_esp32s3, mt8195_adsp)

The following host tools are available as part of the Zephyr SDK:

BOSSA
OpenOCD
QEMU
Xilinx QEMU

Releases

The Zephyr SDK bundle releases are available for the following host platforms:

Linux (AArch64, x86-64)
macOS (AArch64, x86-64)
Windows (x86-64)

These binaries can be downloaded from here.

For future release plans, please refer to the Release Plan document in the wiki.

Build Process

The Zephyr Project maintains the infrastructure necessary to build and test the Zephyr SDK, and it is highly recommended to utilise this infrastructure for generating the Zephyr SDK binaries.

When you submit a pull request to the Zephyr SDK repository, CI will automatically build and test the Zephyr SDK with the changes in the pull request and upload the binaries to the pull request check run, which you can download for further local testing as necessary.

To aid in verifying changes and introduction of a new toolchain, a helper script, contrib/linux_build_toolchain.sh, can be used to build one toolchain under Linux.

Workflow to Test Patches with Zephyr SDK

The following workflow can be used to test a patch for GCC, for example, building the SDK remotely:

Submit your DRAFT gcc PR to Zephyr's GCC fork (etc.)
Update .gitmodules in sdk-ng to point to the fork with your gcc commit(s)
Resync submodules (git submodule sync --recursive && cd gcc && git pull)
Checkout the gcc commit hash in sdk-ng's gcc submodule and commit the .gitmodule changes (git add .gitmodules gcc && git commit -s)
Submit a DRAFT PR to sdk-ng with the submodule change(s)

Zephyr's CI will then build a new toolchain, which will be available in the PR check step. Verify that the GCC fix behaves as expected with the generated SDK.

Release Process

To create a new Zephyr SDK release:

Update the VERSION file with the new version (e.g. 0.11.0 or 0.11.0-beta1)
On https://github.com/zephyrproject-rtos/sdk-ng/releases, create a new tag named with the version number prefixed with v (e.g. for the version 0.11.0, the tag name should be v0.11.0) and add the release information.
Once the release is published, CI will build the Zephyr SDK bundles for all supported host platforms and will upload the binaries to the release page.

For more detailed information on the release process, please refer to the Release Process document in the wiki.

Submodule Update Process

The Zephyr SDK repository contains various submodules, such as binutils and gcc, required for building the Zephyr SDK.

When updating a submodule, the following procedure should be followed:

Push a topic branch to the submodule repository.
Create a pull request from the topic branch to the default (current) branch of the submodule repository.
Create a pull request in the Zephyr SDK repository to update the submodule reference to the tip of the topic (pull request) branch.
When the pull request in the Zephyr SDK repository passes the CI and the submodule pull request is sufficiently reviewed, merge the submodule pull request.
Update the pull request in the Zephyr SDK repository to reference the merged commit in the submodule repository.
Merge the pull request in the Zephyr SDK repository.

When updating the picolibc submodule, the picolibc module in the west.yml of the main Zephyr repository must also be updated to reference the same commit.

sdk-ng's People

Contributors

Stargazers

Watchers

Forkers

nashif gridl galak antoinealb eliminater74 dcpleung mbolivar wcg2000 majay123 wolfury adfernandes jiuzhuaxiong xingdai ioannisg bbolen jiapei100 eeinz craxo nuaazhaoxin ajb042487 nijaling wuxyintel huayuguo stephanosio blake-zhang evgeniididin buddhistinnestle yashi tliqit lgirdwood jiccage romlinux alexeicolin tejlmand xodus7 ntavish abrodkin coollh pabigot dbinev voyager1128 xiongjinqi henrikbrixandersen yperess keith-packard falaleevms sanshah2211 acidburn0zzz babyge 5l1v3r1 carlocaione mikey microbuilder 632718651 mirkocovizzi antmak zzfd97 tuviarap sylvioalves dzungdh pfalcon mrandreastoth a8961713 remy-luisant intgr8 ila-embsys shiqingziyang huajunpx egeeks lgl88911 isabella232 ghchris2021 mfkiwl tryweirdier unrulife evgeniy-paltsev mbrunnen armbiant tari anjaneyareddyk alpsayin hyperion-tech changjianhuang longervisionrobot hugoleee cetech11 zt3ph4n cgray42 jsoref banzhangzzw kealqqq shawn0611 nordicjm alexshi126 sunilkumardommati reddysujith vijendarmukunda tcsyang anobli monjikura

sdk-ng's Issues

toolchain fails to build for arm multilib

When configuring the multilibs to the rmprofile (in arm.config:

CT_CC_GCC_MULTILIB_LIST="rmprofile":

Get the following:

[galak@spiff sdk-ng]$ ./go.sh arm
Building arm
~/git/sdk-ng/build/build_arm ~/git/sdk-ng/build
  CLEAN log
  CLEAN build dir
  CONF  oldconfig
*
* Restart config...
*
*
* Toolchain options
*
*
* General toolchain options
*
Build Static Toolchain (STATIC_TOOLCHAIN) [N/y/?] (NEW) 

Add crosstool-NG version to --version output (SHOW_CT_VERSION) [Y/n/?] y
Toolchain ID string (TOOLCHAIN_PKGVERSION) [] 
Toolchain bug URL (TOOLCHAIN_BUGURL) [] 
*
* Tuple completion and aliasing
*
Tuple's vendor string (TARGET_VENDOR) [zephyr] zephyr
Tuple's sed transform (TARGET_ALIAS_SED_EXPR) [] 
Tuple's alias (TARGET_ALIAS) [] 
*
* Toolchain type
*
Type
> 1. Cross (CROSS)
  2. Canadian (CANADIAN)
choice[1-2]: 1
*
* Build system
*
  Tuple        (READ HELP!) (BUILD) [] 
  Tools prefix (READ HELP!) (BUILD_PREFIX) [] 
  Tools suffix (READ HELP!) (BUILD_SUFFIX) [] 
*
* Misc options
*
Enable nls (TOOLCHAIN_ENABLE_NLS) [N/y/?] n
*
* C compiler
*
Compiler
> 1. gcc (CC_GCC)
choice[1]: 1
Show gcc versions from
> 1. GNU (GCC_USE_GNU)
choice[1]: 1
Source of gcc
> 1. Released tarball (GCC_SRC_RELEASE)
choice[1]: 1
Version of gcc
  1. 8.1.0 (GCC_V_8_1_0)
> 2. 7.3.0 (GCC_V_7_3_0)
  3. 6.4.0 (GCC_V_6_4_0)
  4. 5.5.0 (GCC_V_5_5_0)
  5. 4.9.4 (GCC_V_4_9_4)
  6. 4.8.5 (OBSOLETE) (GCC_V_4_8_5)
choice[1-6?]: 2
Flags to pass to --enable-cxx-flags (CC_GCC_ENABLE_CXX_FLAGS) [] 
Core gcc extra config (CC_GCC_CORE_EXTRA_CONFIG_ARRAY) [] 
gcc extra config (CC_GCC_EXTRA_CONFIG_ARRAY) [] 
List of multilib variants (CC_GCC_MULTILIB_LIST) [rmprofile] rmprofile
Link libstdc++ statically into the gcc binary (CC_GCC_STATIC_LIBSTDCXX) [Y/n/?] (NEW) 

Use system zlib (CC_GCC_SYSTEM_ZLIB) [N/y/?] n
Configure TLS (Thread Local Storage) (CC_GCC_CONFIG_TLS) [M/n/y/?] m
*
* Optimisation features
*
Enable GRAPHITE loop optimisations (CC_GCC_USE_GRAPHITE) [Y/n/?] y
Enable LTO (CC_GCC_USE_LTO) [Y/n/?] y
*
* Settings for libraries running on target
*
Optimize gcc libs for size (CC_GCC_ENABLE_TARGET_OPTSPACE) [Y/n/?] y
Compile libmudflap (CC_GCC_LIBMUDFLAP) [N/y/?] n
Compile libssp (CC_GCC_LIBSSP) [N/y/?] n
Compile libquadmath (CC_GCC_LIBQUADMATH) [N/y/?] n
*
* Misc. obscure options.
*
Use __cxa_atexit (CC_CXA_ATEXIT) [Y/n/?] y
Do not build PCH (CC_GCC_DISABLE_PCH) [N/y/?] n
Enable 128-bit long doubles (CC_GCC_LDBL_128) [M/n/y/?] m
Enable build-id (CC_GCC_BUILD_ID) [N/y/?] n
linker hash style
> 1. Default (CC_GCC_LNK_HASH_STYLE_DEFAULT)
  2. sysv (CC_GCC_LNK_HASH_STYLE_SYSV)
  3. gnu (CC_GCC_LNK_HASH_STYLE_GNU)
  4. both (CC_GCC_LNK_HASH_STYLE_BOTH)
choice[1-4]: 1
Decimal floats
> 1. auto (CC_GCC_DEC_FLOAT_AUTO)
  2. bid (CC_GCC_DEC_FLOAT_BID)
  3. dpd (CC_GCC_DEC_FLOAT_DPD)
  4. no (CC_GCC_DEC_FLOATS_NO)
choice[1-4?]: 1
*
* Additional supported languages:
*
C++ (CC_LANG_CXX) [Y/n/?] y
Fortran (CC_LANG_FORTRAN) [N/y/?] n
*
* gdb
*
gdb (DEBUG_GDB) [Y/n/?] y
  Show gdb versions from
  > 1. GNU (GDB_USE_GNU)
  choice[1]: 1
  Source of gdb
  > 1. Released tarball (GDB_SRC_RELEASE)
  choice[1]: 1
  Version of gdb
  > 1. 8.1 (GDB_V_8_1)
    2. 8.0.1 (GDB_V_8_0_1)
    3. 7.12.1 (GDB_V_7_12_1)
    4. 7.11.1 (GDB_V_7_11_1)
    5. 7.10.1 (OBSOLETE) (GDB_V_7_10_1)
    6. 7.9.1 (OBSOLETE) (GDB_V_7_9_1)
    7. 7.8.1 (OBSOLETE) (GDB_V_7_8_1)
    8. 7.7.1 (OBSOLETE) (GDB_V_7_7_1)
    9. 7.6.1 (OBSOLETE) (GDB_V_7_6_1)
    10. 7.5.1 (OBSOLETE) (GDB_V_7_5_1)
    11. 7.4.1 (OBSOLETE) (GDB_V_7_4_1)
    12. 7.3.1 (OBSOLETE) (GDB_V_7_3_1)
    13. 7.2a (OBSOLETE) (GDB_V_7_2A)
    14. 7.1a (OBSOLETE) (GDB_V_7_1A)
    15. 7.0a (OBSOLETE) (GDB_V_7_0A)
    16. 7.0.1a (OBSOLETE) (GDB_V_7_0_1A)
    17. 6.8a (OBSOLETE) (GDB_V_6_8A)
  choice[1-17?]: 1
  Cross-gdb (GDB_CROSS) [Y/n/?] y
    Build a static cross gdb (GDB_CROSS_STATIC) [N/y/?] (NEW) 

    Enable 'sim' (GDB_CROSS_SIM) [N/y/?] n
    Enable python scripting (GDB_CROSS_PYTHON) [Y/n/?] y
      Python binary to use (GDB_CROSS_PYTHON_BINARY) [] 
    Cross-gdb extra config (GDB_CROSS_EXTRA_CONFIG_ARRAY) [] 
  *
  * In bare-metal, you'll need to   
  *
  *
  * provide your own gdbserver stub.
  *
#
# configuration written to .config
#
[INFO ]  Performing some trivial sanity checks
[INFO ]  Build started 20180717.125142
[INFO ]  Building environment variables
[EXTRA]  Preparing working directories
[EXTRA]  Installing user-supplied crosstool-NG configuration
[EXTRA]  =================================================================
[EXTRA]  Dumping internal crosstool-NG configuration
[EXTRA]    Building a toolchain for:
[EXTRA]      build  = x86_64-pc-linux-gnu
[EXTRA]      host   = x86_64-pc-linux-gnu
[EXTRA]      target = arm-zephyr-eabi
[EXTRA]  Dumping internal crosstool-NG configuration: done in 0.04s (at 00:01)
[INFO ]  =================================================================
[INFO ]  Retrieving needed toolchain components' tarballs
[INFO ]  Retrieving needed toolchain components' tarballs: done in 0.18s (at 00:01)
[INFO ]  =================================================================
[INFO ]  Extracting and patching toolchain components
[EXTRA]    Extracting m4-1.4.18
[EXTRA]    Patching m4-1.4.18
[EXTRA]    Extracting gmp-6.1.2
[EXTRA]    Patching gmp-6.1.2
[EXTRA]    Extracting mpfr-4.0.1
[EXTRA]    Patching mpfr-4.0.1
[EXTRA]    Extracting isl-0.18
[EXTRA]    Patching isl-0.18
[EXTRA]    Extracting mpc-1.1.0
[EXTRA]    Patching mpc-1.1.0
[EXTRA]    Extracting expat-2.2.5
[EXTRA]    Patching expat-2.2.5
[EXTRA]    Extracting ncurses-6.1
[EXTRA]    Patching ncurses-6.1
[EXTRA]    Extracting libiconv-1.15
[EXTRA]    Patching libiconv-1.15
[EXTRA]    Extracting binutils-2.30
[EXTRA]    Patching binutils-2.30
[EXTRA]    Extracting gcc-7.3.0
[EXTRA]    Patching gcc-7.3.0
[EXTRA]    Extracting newlib-2.5.0.20171222
[EXTRA]    Patching newlib-2.5.0.20171222
[EXTRA]    Extracting gdb-8.1
[EXTRA]    Patching gdb-8.1
[INFO ]  Extracting and patching toolchain components: done in 13.05s (at 00:14)
[INFO ]  =================================================================
[INFO ]  Installing m4 for build
[EXTRA]    Configuring m4
[EXTRA]    Building m4
[EXTRA]    Installing m4
[INFO ]  Installing m4 for build: done in 17.70s (at 00:32)
[INFO ]  =================================================================
[INFO ]  Installing ncurses for build
[EXTRA]    Configuring ncurses
[EXTRA]    Building ncurses
[EXTRA]    Installing ncurses
[INFO ]  Installing ncurses for build: done in 7.49s (at 00:39)
[INFO ]  =================================================================
[INFO ]  Installing GMP for host
[EXTRA]    Configuring GMP
[EXTRA]    Building GMP
[EXTRA]    Installing GMP
[INFO ]  Installing GMP for host: done in 18.56s (at 00:58)
[INFO ]  =================================================================
[INFO ]  Installing MPFR for host
[EXTRA]    Configuring MPFR
[EXTRA]    Building MPFR
[EXTRA]    Installing MPFR
[INFO ]  Installing MPFR for host: done in 8.77s (at 01:07)
[INFO ]  =================================================================
[INFO ]  Installing ISL for host
[EXTRA]    Configuring ISL
[EXTRA]    Building ISL
[EXTRA]    Installing ISL
[INFO ]  Installing ISL for host: done in 4.40s (at 01:11)
[INFO ]  =================================================================
[INFO ]  Installing MPC for host
[EXTRA]    Configuring MPC
[EXTRA]    Building MPC
[EXTRA]    Installing MPC
[INFO ]  Installing MPC for host: done in 3.85s (at 01:15)
[INFO ]  =================================================================
[INFO ]  Installing expat for host
[EXTRA]    Configuring expat
[EXTRA]    Building expat
[EXTRA]    Installing expat
[INFO ]  Installing expat for host: done in 4.18s (at 01:19)
[INFO ]  =================================================================
[INFO ]  Installing ncurses for host
[EXTRA]    Configuring ncurses
[EXTRA]    Building ncurses
[EXTRA]    Installing ncurses
[INFO ]  Installing ncurses for host: done in 8.00s (at 01:27)
[INFO ]  =================================================================
[INFO ]  Installing libiconv for host
[EXTRA]    Skipping (included in GNU C library)
[INFO ]  Installing libiconv for host: done in 0.01s (at 01:27)
[INFO ]  =================================================================
[INFO ]  Installing binutils for host
[EXTRA]    Configuring binutils
[EXTRA]    Building binutils
[EXTRA]    Installing binutils
[INFO ]  Installing binutils for host: done in 20.63s (at 01:48)
[INFO ]  =================================================================
[INFO ]  Installing C library headers & start files
[INFO ]  Installing C library headers & start files: done in 0.01s (at 01:48)
[INFO ]  =================================================================
[INFO ]  Installing pass-2 core C gcc compiler
[EXTRA]    Configuring core C gcc compiler
[EXTRA]    Building gcc
[ERROR]    /home/galak/git/sdk-ng/build/build_arm/.build/arm-zephyr-eabi/build/build-cc-gcc-core-pass-2/gcc/include/stdint.h:9:16: fatal error: stdint.h: No such file or directory
[ERROR]    make[4]: *** [/home/galak/git/sdk-ng/build/build_arm/.build/arm-zephyr-eabi/src/gcc/libgcc/config/arm/t-arm:14: cmse.o] Error 1
[ERROR]    make[4]: *** Waiting for unfinished jobs....
[ERROR]    make[3]: *** [Makefile:1198: multi-do] Error 1
[ERROR]    make[2]: *** [Makefile:125: all-multi] Error 2
[ERROR]    make[1]: *** [Makefile:11511: all-target-libgcc] Error 2
[ERROR]  
[ERROR]  >>
[ERROR]  >>  Build failed in step 'Installing pass-2 core C gcc compiler'
[ERROR]  >>        called in step '(top-level)'
[ERROR]  >>
[ERROR]  >>  Error happened in: CT_DoExecLog[scripts/functions@374]
[ERROR]  >>        called from: do_gcc_core_backend[scripts/build/cc/gcc.sh@671]
[ERROR]  >>        called from: do_cc_core_pass_2[scripts/build/cc/gcc.sh@257]
[ERROR]  >>        called from: main[scripts/crosstool-NG.sh@679]
[ERROR]  >>
[ERROR]  >>  For more info on this error, look at the file: 'build.log'
[ERROR]  >>  There is a list of known issues, some with workarounds, in:
[ERROR]  >>      https://crosstool-ng.github.io/docs/known-issues/
[ERROR]  >>
[ERROR]  >>  If you feel this is a bug in crosstool-NG, report it at:
[ERROR]  >>      https://github.com/crosstool-ng/crosstool-ng/issues/
[ERROR]  >>
[ERROR]  >>  Make sure your report includes all the information pertinent to this issue.
[ERROR]  >>  Read the bug reporting guidelines here:
[ERROR]  >>      http://crosstool-ng.github.io/support/
[ERROR]  
[ERROR]  (elapsed: 4:02.86)
gmake: *** [/home/galak/git/sdk-ng/bin/ct-ng:232: build] Error 2
~/git/sdk-ng/build

qemu_x86: no coverage data is produced

When doing coverage with qemu_x86, there is nothing between GCOV_COVERAGE_DUMP_START and GCOV_COVERAGE_DUMP_END in the output, and thus no coverage data is produced. This is due to __gcov_init() not being called. The gcov_static_init() requires an array of init functions to call, but under i586, there is no such init array being produced by compiler.

This is fixed by PR #57 by enabling the --enable-initfini-array for the i586 toolchain.

latest bossac tool in SDK not working

Having issues when flashing arduino_due images using latest SDK. Reverting back to the version we had in previous SDK works fine.

64 bit print format specifiers not defined

Have upgraded SDK from 0.9.5 to 0.10.0. Looks like PRId64 and friends are no longer defined
(PRId32 etc are) ? Am building zephyr off head for the ARM frdm_k64f.

Support multiple newlib variants (normal and nano)

The Newlib library, included as part of embedded toolchains (e.g. GNU ARM Embedded), is often available in two forms: normal (libc.a, libg.a, ...) and nano (libc_nano.a, libg_nano.a,, ...).

Zephyr SDK only builds the nano-like variant as the main C runtime library used by the GCC (libc.a, libg.a, ...), and this yields an unacceptable level of performance for essential runtime functions (e.g. memset and memcpy), as detailed in the issue #151.

This is partly due to the inherent limitation of crosstool-ng, which is used to build the toolchains including GCC and Newlib, that it does not allow specifying multiple newlib build configurations for single target; hence, making it impossible for the normal and nano newlib variants to coexist.

Since the performance limitations of the nano variant is so severe, it is imperative that both variants are available in the Zephyr SDK to support a wide variety of devices.

Using the ARM microcontroller architectures as an example, it would be desirable to link the nano variant for the Cortex-M0 and -M0+ devices where the available memory space is very limited, while the normal variant would be more desirable for the less memory-constrained Cortex-M3 and -M4 devices; as for Cortex-M7, there would be no justification whatsoever for linking the nano variant given its performance limitations.

In order to support multiple newlib variants, the following changes should be implemented:

Add nano variant-specific newlib configurations to the crosstool-ng (crosstool-ng/config/libc/newlib.in).
- Keep all LIBC_NEWLIB_... configs as is. These configurations will be used to build the normal variant (libc.a, libg.a ...).
- Mirror all LIBC_NEWLIB_... configs to LIBC_NANO_NEWLIB_... configs. These configurations will be used to build the nano variant (libc_nano.a, libg_nano.a ...).
Modify crosstool-ng build script to build LIBC and LIBC_NANO variants separately.
Apply newlib normal and nano variant configurations (based on the GNU ARM Embedded build script) to the Zephyr SDK crosstool-ng build configs.
- Apply normal variant configurations to LIBC_NEWLIB_... configs.
- Apply nano variant configurations to LIBC_NANO_NEWLIB_... configs.

arc emsk's openocd debugger doesn't work in Zephyr SDK 0.9.5

Describe the bug
After Zephyr SDK updated to 0.9.5, the openocd debugger of arc em_starterkit doesn't work correctly.

To Reproduce
Steps to reproduce the behavior:

mkdir build; cd build
cmake -DBOARD=em_starterkit_em7d ..
make
west debug
see error

Expected behavior
the debugger cann't run because of error caused by openocd.

Impact
can't debug the em_starterkit hardware

Screenshots or console output
The log is as follow:

Using runner: em-starterkit
Open On-Chip Debugger 0.10.0+dev-gea2753a7-dirty (2018-11-02-23:37)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
none separate
adapter speed: 5000 kHz
Info : clock speed 5000 kHz
Info : JTAG tap: arc-em.cpu tap/device found: 0x200044b1 (mfg: 0x258 (ARC International), part: 0x0004, ver: 0x2)
Register `identity' is not found.
in procedure 'init'
in procedure 'ocd_bouncer'

Info : Listening on port 3333 for gdb connections
TargetName Type Endian TapName State

0* arc-em.cpu arcv2 little arc-em.cpu halted
Info : Listening on port 6333 for tcl connections
Info : Listening on port 4444 for telnet connections
GNU gdb (GDB) 7.12.0.20161010-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-pokysdk-linux --target=arc-zephyr-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/wren/zephyr/samples/philosophers/emsk/zephyr/zephyr.elf...done.
Info : accepting 'gdb' connection on tcp/3333
Remote debugging using :3333
warning: while parsing target description (at line 6): Boolean fields must be one bit in size
warning: Could not load XML target description; ignoring
openocd: src/server/gdb_server.c:1188: gdb_get_registers_packet: Assertion `reg_packet_size > 0' failed.
Remote connection closed

Environment (please complete the following information):

OS: Linux/Debian
Toolchain (Zephyr SDK)
latest commit

Additional context
Add any other context about the problem here.

newlib-nano not supported on all targets

Need to add spec file for nano configs that are supported by default in newlib.

Add aarch64-zephyr-elf target

Add aarch64-zephyr-elf target support, in preparation for Cortex-A AArch64 port.

Toolchain build fails for ARM

I tried to use the provided script to build the ARM toolchain, on master branch.
Build failed, with the following log:

Building arm
~/Documents/workspace/sdk-ng/build/build_arm ~/Documents/workspace/sdk-ng/build
  CLEAN log
  CLEAN build dir
  CONF  oldconfig
*
* Restart config...
*
*
* Toolchain options
*
*
* General toolchain options
*
Build Static Toolchain (STATIC_TOOLCHAIN) [N/y/?] (NEW) 

Add crosstool-NG version to --version output (SHOW_CT_VERSION) [Y/n/?] y
Toolchain ID string (TOOLCHAIN_PKGVERSION) [] 
Toolchain bug URL (TOOLCHAIN_BUGURL) [] 
*
* Tuple completion and aliasing
*
Tuple's vendor string (TARGET_VENDOR) [zephyr] zephyr
Tuple's sed transform (TARGET_ALIAS_SED_EXPR) [] 
Tuple's alias (TARGET_ALIAS) [] 
*
* Toolchain type
*
Type
> 1. Cross (CROSS)
  2. Canadian (CANADIAN)
choice[1-2]: 1
*
* Build system
*
  Tuple        (READ HELP!) (BUILD) [] 
  Tools prefix (READ HELP!) (BUILD_PREFIX) [] 
  Tools suffix (READ HELP!) (BUILD_SUFFIX) [] 
*
* Misc options
*
Enable nls (TOOLCHAIN_ENABLE_NLS) [N/y/?] n
*
* C compiler
*
Compiler
> 1. gcc (CC_GCC)
choice[1]: 1
Show gcc versions from
> 1. GNU (GCC_USE_GNU)
choice[1]: 1
Source of gcc
> 1. Released tarball (GCC_SRC_RELEASE)
choice[1]: 1
Version of gcc
  1. 8.1.0 (GCC_V_8_1_0)
> 2. 7.3.0 (GCC_V_7_3_0)
  3. 6.4.0 (GCC_V_6_4_0)
  4. 5.5.0 (GCC_V_5_5_0)
  5. 4.9.4 (GCC_V_4_9_4)
  6. 4.8.5 (OBSOLETE) (GCC_V_4_8_5)
choice[1-6?]: 2
Flags to pass to --enable-cxx-flags (CC_GCC_ENABLE_CXX_FLAGS) [] 
Core gcc extra config (CC_GCC_CORE_EXTRA_CONFIG_ARRAY) [] 
gcc extra config (CC_GCC_EXTRA_CONFIG_ARRAY) [] 
List of multilib variants (CC_GCC_MULTILIB_LIST) [] 
Link libstdc++ statically into the gcc binary (CC_GCC_STATIC_LIBSTDCXX) [Y/n/?] (NEW) 

Use system zlib (CC_GCC_SYSTEM_ZLIB) [N/y/?] n
Configure TLS (Thread Local Storage) (CC_GCC_CONFIG_TLS) [M/n/y/?] m
*
* Optimisation features
*
Enable GRAPHITE loop optimisations (CC_GCC_USE_GRAPHITE) [Y/n/?] y
Enable LTO (CC_GCC_USE_LTO) [Y/n/?] y
*
* Settings for libraries running on target
*
Optimize gcc libs for size (CC_GCC_ENABLE_TARGET_OPTSPACE) [Y/n/?] y
Compile libmudflap (CC_GCC_LIBMUDFLAP) [N/y/?] n
Compile libssp (CC_GCC_LIBSSP) [N/y/?] n
Compile libquadmath (CC_GCC_LIBQUADMATH) [N/y/?] n
*
* Misc. obscure options.
*
Use __cxa_atexit (CC_CXA_ATEXIT) [Y/n/?] y
Do not build PCH (CC_GCC_DISABLE_PCH) [N/y/?] n
Enable 128-bit long doubles (CC_GCC_LDBL_128) [M/n/y/?] m
Enable build-id (CC_GCC_BUILD_ID) [N/y/?] n
linker hash style
> 1. Default (CC_GCC_LNK_HASH_STYLE_DEFAULT)
  2. sysv (CC_GCC_LNK_HASH_STYLE_SYSV)
  3. gnu (CC_GCC_LNK_HASH_STYLE_GNU)
  4. both (CC_GCC_LNK_HASH_STYLE_BOTH)
choice[1-4]: 1
Decimal floats
> 1. auto (CC_GCC_DEC_FLOAT_AUTO)
  2. bid (CC_GCC_DEC_FLOAT_BID)
  3. dpd (CC_GCC_DEC_FLOAT_DPD)
  4. no (CC_GCC_DEC_FLOATS_NO)
choice[1-4?]: 1
*
* Additional supported languages:
*
C++ (CC_LANG_CXX) [Y/n/?] y
Fortran (CC_LANG_FORTRAN) [N/y/?] n
*
* gdb
*
gdb (DEBUG_GDB) [Y/n/?] y
  Show gdb versions from
  > 1. GNU (GDB_USE_GNU)
  choice[1]: 1
  Source of gdb
  > 1. Released tarball (GDB_SRC_RELEASE)
  choice[1]: 1
  Version of gdb
  > 1. 8.1 (GDB_V_8_1)
    2. 8.0.1 (GDB_V_8_0_1)
    3. 7.12.1 (GDB_V_7_12_1)
    4. 7.11.1 (GDB_V_7_11_1)
    5. 7.10.1 (OBSOLETE) (GDB_V_7_10_1)
    6. 7.9.1 (OBSOLETE) (GDB_V_7_9_1)
    7. 7.8.1 (OBSOLETE) (GDB_V_7_8_1)
    8. 7.7.1 (OBSOLETE) (GDB_V_7_7_1)
    9. 7.6.1 (OBSOLETE) (GDB_V_7_6_1)
    10. 7.5.1 (OBSOLETE) (GDB_V_7_5_1)
    11. 7.4.1 (OBSOLETE) (GDB_V_7_4_1)
    12. 7.3.1 (OBSOLETE) (GDB_V_7_3_1)
    13. 7.2a (OBSOLETE) (GDB_V_7_2A)
    14. 7.1a (OBSOLETE) (GDB_V_7_1A)
    15. 7.0a (OBSOLETE) (GDB_V_7_0A)
    16. 7.0.1a (OBSOLETE) (GDB_V_7_0_1A)
    17. 6.8a (OBSOLETE) (GDB_V_6_8A)
  choice[1-17?]: 1
  Cross-gdb (GDB_CROSS) [Y/n/?] y
    Build a static cross gdb (GDB_CROSS_STATIC) [N/y/?] (NEW) 

    Enable 'sim' (GDB_CROSS_SIM) [N/y/?] n
    Enable python scripting (GDB_CROSS_PYTHON) [Y/n/?] y
      Python binary to use (GDB_CROSS_PYTHON_BINARY) [] 
    Cross-gdb extra config (GDB_CROSS_EXTRA_CONFIG_ARRAY) [] 
  *
  * In bare-metal, you'll need to   
  *
  *
  * provide your own gdbserver stub.
  *
#
# configuration written to .config
#
[INFO ]  Performing some trivial sanity checks
[INFO ]  Build started 20180713.174306
[INFO ]  Building environment variables
[EXTRA]  Preparing working directories
[EXTRA]  Installing user-supplied crosstool-NG configuration
[EXTRA]  =================================================================
[EXTRA]  Dumping internal crosstool-NG configuration
[EXTRA]    Building a toolchain for:
[EXTRA]      build  = x86_64-pc-linux-gnu
[EXTRA]      host   = x86_64-pc-linux-gnu
[EXTRA]      target = arm-zephyr-eabi
[EXTRA]  Dumping internal crosstool-NG configuration: done in 0.05s (at 00:01)
[INFO ]  =================================================================
[INFO ]  Retrieving needed toolchain components' tarballs
[INFO ]  Retrieving needed toolchain components' tarballs: done in 0.14s (at 00:01)
[INFO ]  =================================================================
[INFO ]  Extracting and patching toolchain components
[EXTRA]    Extracting m4-1.4.18
[EXTRA]    Patching m4-1.4.18
[EXTRA]    Extracting gmp-6.1.2
[EXTRA]    Patching gmp-6.1.2
[EXTRA]    Extracting mpfr-4.0.1
[EXTRA]    Patching mpfr-4.0.1
[EXTRA]    Extracting isl-0.18
[EXTRA]    Patching isl-0.18
[EXTRA]    Extracting mpc-1.1.0
[EXTRA]    Patching mpc-1.1.0
[EXTRA]    Extracting expat-2.2.5
[EXTRA]    Patching expat-2.2.5
[EXTRA]    Extracting ncurses-6.1
[EXTRA]    Patching ncurses-6.1
[EXTRA]    Extracting libiconv-1.15
[EXTRA]    Patching libiconv-1.15
[EXTRA]    Extracting binutils-2.30
[EXTRA]    Patching binutils-2.30
[EXTRA]    Extracting gcc-7.3.0
[EXTRA]    Patching gcc-7.3.0
[EXTRA]    Extracting newlib-2.5.0.20171222
[EXTRA]    Patching newlib-2.5.0.20171222
[EXTRA]    Extracting gdb-8.1
[EXTRA]    Patching gdb-8.1
[INFO ]  Extracting and patching toolchain components: done in 25.65s (at 00:27)
[INFO ]  =================================================================
[INFO ]  Installing m4 for build
[EXTRA]    Configuring m4
[EXTRA]    Building m4
[EXTRA]    Installing m4
[INFO ]  Installing m4 for build: done in 22.34s (at 00:49)
[INFO ]  =================================================================
[INFO ]  Installing ncurses for build
[EXTRA]    Configuring ncurses
[EXTRA]    Building ncurses
[EXTRA]    Installing ncurses
[INFO ]  Installing ncurses for build: done in 26.25s (at 01:16)
[INFO ]  =================================================================
[INFO ]  Installing GMP for host
[EXTRA]    Configuring GMP
[EXTRA]    Building GMP
[EXTRA]    Installing GMP
[INFO ]  Installing GMP for host: done in 59.17s (at 02:15)
[INFO ]  =================================================================
[INFO ]  Installing MPFR for host
[EXTRA]    Configuring MPFR
[EXTRA]    Building MPFR
[EXTRA]    Installing MPFR
[INFO ]  Installing MPFR for host: done in 54.83s (at 03:10)
[INFO ]  =================================================================
[INFO ]  Installing ISL for host
[EXTRA]    Configuring ISL
[EXTRA]    Building ISL
[EXTRA]    Installing ISL
[INFO ]  Installing ISL for host: done in 41.53s (at 03:51)
[INFO ]  =================================================================
[INFO ]  Installing MPC for host
[EXTRA]    Configuring MPC
[EXTRA]    Building MPC
[EXTRA]    Installing MPC
[INFO ]  Installing MPC for host: done in 10.07s (at 04:01)
[INFO ]  =================================================================
[INFO ]  Installing expat for host
[EXTRA]    Configuring expat
[EXTRA]    Building expat
[EXTRA]    Installing expat
[INFO ]  Installing expat for host: done in 7.82s (at 04:09)
[INFO ]  =================================================================
[INFO ]  Installing ncurses for host
[EXTRA]    Configuring ncurses
[EXTRA]    Building ncurses
[EXTRA]    Installing ncurses
[INFO ]  Installing ncurses for host: done in 25.99s (at 04:35)
[INFO ]  =================================================================
[INFO ]  Installing libiconv for host
[EXTRA]    Skipping (included in GNU C library)
[INFO ]  Installing libiconv for host: done in 0.01s (at 04:35)
[INFO ]  =================================================================
[INFO ]  Installing binutils for host
[EXTRA]    Configuring binutils
[EXTRA]    Building binutils
[EXTRA]    Installing binutils
[INFO ]  Installing binutils for host: done in 100.20s (at 06:15)
[INFO ]  =================================================================
[INFO ]  Installing C library headers & start files
[INFO ]  Installing C library headers & start files: done in 0.05s (at 06:15)
[INFO ]  =================================================================
[INFO ]  Installing pass-2 core C gcc compiler
[EXTRA]    Configuring core C gcc compiler
[EXTRA]    Building gcc
[ERROR]    make[2]: *** [generic-match.o] Error 1
[ERROR]    make[2]: *** Waiting for unfinished jobs....
[ERROR]    make[1]: *** [all-gcc] Error 2
[ERROR]  
[ERROR]  >>
[ERROR]  >>  Build failed in step 'Installing pass-2 core C gcc compiler'
[ERROR]  >>        called in step '(top-level)'
[ERROR]  >>
[ERROR]  >>  Error happened in: CT_DoExecLog[scripts/functions@374]
[ERROR]  >>        called from: do_gcc_core_backend[scripts/build/cc/gcc.sh@671]
[ERROR]  >>        called from: do_cc_core_pass_2[scripts/build/cc/gcc.sh@257]
[ERROR]  >>        called from: main[scripts/crosstool-NG.sh@679]
[ERROR]  >>
[ERROR]  >>  For more info on this error, look at the file: 'build.log'
[ERROR]  >>  There is a list of known issues, some with workarounds, in:
[ERROR]  >>      https://crosstool-ng.github.io/docs/known-issues/
[ERROR]  >>
[ERROR]  >>  If you feel this is a bug in crosstool-NG, report it at:
[ERROR]  >>      https://github.com/crosstool-ng/crosstool-ng/issues/
[ERROR]  >>
[ERROR]  >>  Make sure your report includes all the information pertinent to this issue.
[ERROR]  >>  Read the bug reporting guidelines here:
[ERROR]  >>      http://crosstool-ng.github.io/support/
[ERROR]  
[ERROR]  (elapsed: 17:26.01)
/home/ioannisg/Documents/workspace/sdk-ng/bin/ct-ng:232: recipe for target 'build' failed
make: *** [build] Error 2
~/Documents/workspace/sdk-ng/build

Zephyr SDK's newlib doesn't support long long specifiers in printf

In a Zephyr application with CONFIG_NEWLIB_LIBC, I'm doing printf("%lld\n", foo); and get ld as output. Ditto for "%llu".

According to https://stackoverflow.com/a/32949522/496009, newlib's long long printf support is disabled by default, and must be enabled with --enable-newlib-io-long-long option to configure.

We should consider whether we want to enable that. But not having support for 64-bit value printing is weird.

(Report is based on samples/net/sockets/sntp_client's usage of LOG_DBG("time: %lld", epoch_time);. That doesn't work (what's printed is time: ERR). Heck, even printf("%lld") doesn't work.)

When support armv8 in toolchain - patch arm_cmse.h

The arm_cmse.h header uses typeof and it should really be using __typeof__

Create architecture-specific SDKs

Today's SDK contains tools for all supported architectures in one installable package that's a very large (1,091MB) zephyr-sdk-0.10.3-setup.run download that, I've observed, taking 20 minutes to download. Developers typically have a specific board they're using and don't need tools for other architectures. Having an architecture-specific SDK would reduce the setup time (and clutter) on their development systems.

It appears that the go.sh script used to generate the SDK can create architecture-specific SDKs already, but we're using the "all" option to build the single combined SDK. Can we investigate publishing the combined and architecture-specific SDKs.

SDK migration 0.9.5 -> 0.10.0 increase CPU usage

Describe the bug
New SDK 0.10.0 toolchain seems to significantly increase CPU usage, the new SDK 0.10.0 Newlib a lot.

Test case
I do CPU average usage test on an audio compression task using the opus codec.

Measures
With CONFIG_SPEED_OPTIMIZATIONS=y

SDK 0.9.5

Newlibc => 51% CPU usage
minimal lib => 58% CPU usage

SDK 0.10.0

Newlibc => 75% CPU usage
minimal lib => 60% CPU usage

This gives
CPU usage between SDK 0.9.5 and SDK 0.10.0 with Newlibc : +47%
CPU usage between SDK 0.9.5 and SDK 0.10.0 with minimal lib : +3%

Investigations
SDK 0.9.5 is built on newllib 2.4.0
SDK 0.10.0 is built on newlib 3.1.0,

But it seem that there is no difference on string function source code (memmove, memcpy, memset),

Assumption (in my test case)
SDK 0.10.0 toolchain reduce the CPU performance vs the SDK 0.9.5 of about 3%
Newlibc is compiled differently between the SDK 0.9.5 and the SDK 0.10.0 as it increase the CPU usage of about 47-3 = 44%
On SDK 0.9.5 Newlib is more efficient that minial lib of about 58-51 = 7%

Trial
I replace the source code of the three more used function (memmove, memcpy, memset) in minimal lib with the one from Newlib source.
I build my projet with the SDK 0.10.0

Measures
CPU usage : 53%
=> gain from minimal libc current source code of -13%
=> gain from Newlib : - 41%
=> I find the performance I had with NewLib and SDK 0.9.5 with additional CPU usage of about 4%

Suggestions for improvement

compile newlib differently in SDK
use improved code for the minimal lib

To Reproduce
It'is possible to use my application code for example, but it should be the same with any application using intensive processing and the libc string functions : memset, memcp and especially memmove in my case.

On a nrf52DK pca_nrf52840_pca10056 :
git clone https://github.com/ubicore/nrf52_audio_opus_sgtl5000.git
git clone https://github.com/zephyrproject-rtos/zephyr.git
checkout nrf52_audio_opus_sgtl5000

zephyr-app-commands::
:zephyr-app: nrf52_audio_opus_sgtl5000
:board: nrf52840_pca10056
:conf: "prj.conf overlay-cpustats.conf overlay-audio.conf overlay-oled.conf overlay-sgtl5000.conf"

posix: Build errors when newlib and pthread support are enabled

Describe the bug
When building with CONFIG_NEWLIB_LIBC=y and pthread support enabled, build errors such as the following are seen:

[ 70%] Building C object zephyr/lib/posix/CMakeFiles/lib__posix.dir/pthread_cond.c.obj
In file included from /home/zephyrproject-work/zephyr/include/posix/pthread.h:13,
                 from /home/zephyrproject-work/zephyr/lib/posix/pthread_cond.c:10:
/home/zephyrproject-work/zephyr/include/posix/unistd.h:19:22: error: conflicting types for 'mode_t'
 typedef unsigned int mode_t;
                      ^~~~~~
In file included from /home/zephyrproject-work/zephyr/include/posix/sys/types.h:15,
                 from /home/zephyrproject-work/zephyr/include/posix/time.h:30,
                 from /home/zephyrproject-work/zephyr/include/posix/pthread.h:12,
                 from /home/zephyrproject-work/zephyr/lib/posix/pthread_cond.c:10:
/home/zephyr-sdk-0.10.0-rc2/i586-zephyr-elf/i586-zephyr-elf/sys-include/sys/types.h:205:18: note: previous declaration of 'mode_t' was here
 typedef __mode_t mode_t;  /* permissions */
                  ^~~~~~
zephyr/lib/posix/CMakeFiles/lib__posix.dir/build.make:75: recipe for target 'zephyr/lib/posix/CMakeFiles/lib__posix.dir/pthread_cond.c.obj' failed
make[2]: *** [zephyr/lib/posix/CMakeFiles/lib__posix.dir/pthread_cond.c.obj] Error 1
CMakeFiles/Makefile2:1164: recipe for target 'zephyr/lib/posix/CMakeFiles/lib__posix.dir/all' failed
make[1]: *** [zephyr/lib/posix/CMakeFiles/lib__posix.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

Issue is not seen when building with the Zephyr SDK 0.9.5.

To Reproduce
Steps to reproduce the behavior:

cd samples/hello_world
Add these lines to prj.conf:

CONFIG_NEWLIB_LIBC=y
CONFIG_PTHREAD_IPC=y
CONFIG_POSIX_API=y
CONFIG_MAX_PTHREAD_COUNT=20

mkdir build; cd build
cmake .. -DBOARD=qemu_x86
make
See error

Expected behavior
I would expect to build to succeed with these settings.

Impact
Using newlib and posix leads to build errors.

Environment (please complete the following information):

OS: Ubuntu 18.04
Toolchain: zephyr-sdk-0.10.0-rc2
Commit SHA: 4c21bab620c659c6d7a06558b9bf43e2239799fb

Failed to run "hello_world" sample when building for arm and using trunc() function (from libm)

I'm building the sample app "hello_world" to which I've added one line that uses trunc() function:

#include <zephyr.h>
#include <sys/printk.h>
#include <math.h>

void main(void)
{
        volatile int i = trunc(34);
	printk("Hello World! %s\n", CONFIG_BOARD);
}

I'm building the sample for the KW41z board and when running I get an exception for the trunc() function.

The trunc() function can be found in libm.a library that comes with the SDK.

When I build the project using the ARM-EMBED toolchain the sample runs.
I've used the "7-2018-q2-update" and "8-2019-q3-update" toolchain variants from ARM-EMBED.

Failed to build zephyr-sdk ( sdk-ng )

Hi, all:

My host environments:

➜  ~ uname -a
Linux lvision-GT72-6QE 5.0.0-21-generic #22-Ubuntu SMP Tue Jul 2 13:27:33 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
➜  ~ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 19.04
Release:	19.04
Codename:	disco
➜  ~ gcc --version
gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I can successfully install zephyr-sdk release Zephyr SDK 0.10.1, but failed to build zephyr-sdk for riscv32 with the following ERROR messages:

➜  sdk-ng git:(master) ✗ ./go.sh riscv32           
Building riscv32
....../sdk-ng/build/build_riscv32 ....../sdk-ng/build
  CLEAN log
  CLEAN build dir
  CONF  defconfig
#
# configuration written to .config
#
  GEN   savedefconfig
[INFO ]  Performing some trivial sanity checks
[ERROR]  Don't set LD_LIBRARY_PATH. It screws up the build.
[ERROR]  
[ERROR]  >>
[ERROR]  >>  Build failed in step '(top-level)'
[ERROR]  >>
[ERROR]  >>  Error happened in: CT_Abort[scripts/functions@487]
[ERROR]  >>        called from: CT_TestAndAbort[scripts/functions@507]
[ERROR]  >>        called from: main[scripts/crosstool-NG.sh@56]
[ERROR]  >>
[ERROR]  >>  For more info on this error, look at the file: 'build.log'
[ERROR]  >>  There is a list of known issues, some with workarounds, in:
[ERROR]  >>      https://crosstool-ng.github.io/docs/known-issues/
[ERROR]  >>
[ERROR]  >> NOTE: Your configuration includes features marked EXPERIMENTAL.
[ERROR]  >> Before submitting a bug report, try to reproduce it without enabling
[ERROR]  >> any experimental features. Otherwise, you'll need to debug it
[ERROR]  >> and present an explanation why it is a bug in crosstool-NG - or
[ERROR]  >> preferably, a fix.
[ERROR]  >>
[ERROR]  >> NOTE: You configuration uses non-default patch sets. Please
[ERROR]  >> select 'bundled' as the set of patches applied and attempt
[ERROR]  >> to reproduce this issue. Issues reported with other patch
[ERROR]  >> set selections (none, local, bundled+local) are going to be
[ERROR]  >> closed without explanation.
[ERROR]  >>
[ERROR]  >>  If you feel this is a bug in crosstool-NG, report it at:
[ERROR]  >>      https://github.com/crosstool-ng/crosstool-ng/issues/
[ERROR]  >>
[ERROR]  >>  Make sure your report includes all the information pertinent to this issue.
[ERROR]  >>  Read the bug reporting guidelines here:
[ERROR]  >>      http://crosstool-ng.github.io/support/
[ERROR]  
[ERROR]  (elapsed: 26080105:23.16)
make: *** [....../sdk-ng/bin/ct-ng:261: build] Error 1

Any suggestions?

Thank you very much.
Pei

Support building on Ubuntu 18.04 host

Support building meta-zephyr-sdk of sdk-ng on Ubuntu 18.04 host.

The following patches should be added:

Add a patch for updating poky automake version from 1.15 to 1.15.1
- Ubuntu 18.04 comes with Perl 5.26 and this version of automake 1.15 has compatibility issues with it
- See https://lists.gnu.org/archive/html/info-gnu/2017-06/msg00007.html for more details
Add a patch for patching poky cross-localedef-native_2.24
- locale_t.h needs to be patched to work
- See http://www.programmersought.com/article/9952239705
Add a patch for patching poky elfutils 0.148 and 0.166
- The host GCC on Ubuntu 18.04 treats fall-through warnings as errors by default
- See https://patchwork.openembedded.org/patch/141146
Add a patch for patching poky e2fsprogs
- type-conflict due to including unistd.h in create_inode.c
- See https://blog.csdn.net/weixin_42421766/article/details/82986672
Add a patch for patching poky gcc 6.2
- Fix comparison between pointer and integer in ubsan.c
- See qca/open-ath9k-htc-firmware#135

hello world fails to build with 0.11.0-alpha4 on intel_s1000_crb

./scripts/sanitycheck -s samples/hello_world/sample.helloworld -p intel_s1000_crb
Get the following error:

/home/galak/git/z-sdk-test/zephyr/soc/xtensa/intel_s1000/soc.c:8:10: fatal error: xtensa_api.h: No such file or directory
    8 | #include <xtensa_api.h>
      |          ^~~~~~~~~~~~~~

aarch64 Toolchain wont run on aarch64 Manjaro

I may be completely wrong here, but I'm getting the following error, and I suspect it is improperly built arm64 binaries. It may also be that I have installed the wrong sdk -- but I tried both the risc64-zephyr-elf and the aarch64-zephyr-elf packages to no avail.

Trying to get a Risc V environment setup on my aarch64 Pinebook Pro running Manjaro. I realize this is a bit of an "out there" request.

evantaylor at Pinebook-Pro in ~/Projects/zephyr/samples/hello_world/build (master●) 
$ cmake -DBOARD=hifive1 ..
-- Zephyr version: 2.1.99
-- Selected BOARD hifive1
-- Found west: /usr/bin/west (found suitable version "0.6.3", minimum required is "0.6.0")
CMake Error at /home/evantaylor/Projects/zephyr/cmake/compiler/gcc/generic.cmake:24 (message):
  Executing the below command failed.  Are permissions set correctly?

  '/opt/zephyr-sdk/aarch64-zephyr-elf/bin/aarch64-zephyr-elf-gcc --version'

Call Stack (most recent call first):
  /home/evantaylor/Projects/zephyr/cmake/generic_toolchain.cmake:70 (include)
  /home/evantaylor/Projects/zephyr/cmake/app/boilerplate.cmake:459 (include)
  CMakeLists.txt:5 (include)


-- Configuring incomplete, errors occurred!

Running SDK 0.11.1 and Zephyr Master Branch.

with a modified generic.cmake to point to aarch64 binaries:

evantaylor at Pinebook-Pro in ~/Projects/zephyr/cmake/toolchain/zephyr/0.11 (master●) 
$ cat generic.cmake 
# SPDX-License-Identifier: Apache-2.0

set(TOOLCHAIN_HOME ${ZEPHYR_SDK_INSTALL_DIR})

set(COMPILER gcc)
set(LINKER ld)
set(BINTOOLS gnu)

set(CROSS_COMPILE_TARGET aarch64-${TOOLCHAIN_VENDOR}-elf)
set(SYSROOT_TARGET       aarch64-${TOOLCHAIN_VENDOR}-elf)

set(CROSS_COMPILE ${TOOLCHAIN_HOME}/${CROSS_COMPILE_TARGET}/bin/${CROSS_COMPILE_TARGET}-)
set(SYSROOT_DIR ${ZEPHYR_SDK_INSTALL_DIR}/sysroots/${SYSROOT_TARGET}/usr)
set(TOOLCHAIN_HAS_NEWLIB ON CACHE BOOL "True if toolchain supports newlib")

Zephyr RTOS not detected by OpenOCD for v0.11.0 with ARC target

OpenOCD reports Warn: No RTOS could be auto-detected! and thus Zephyr thread information is not available:

Warn : No RTOS could be auto-detected!
Loading section text, size 0x4cf8 lma 0x0
Loading section sw_isr_table, size 0x408 lma 0x4cf8
Loading section devconfig, size 0xc0 lma 0x5100
Loading section rodata, size 0x42c lma 0x51c0
Loading section datas, size 0x380 lma 0x80000000
Loading section initlevel, size 0xc0 lma 0x80000380
Loading section _static_thread_area, size 0x240 lma 0x80000440
Loading section _k_mem_pool_area, size 0x1c lma 0x80000680
Loading section _k_mutex_area, size 0x14 lma 0x8000069c
Loading section _k_queue_area, size 0x10 lma 0x800006b0
Start address 0x26e8, load size 23724
Transfer rate: 227 KB/sec, 2156 bytes/write.
(gdb)

prj.conf contains:

CONFIG_OPENOCD_SUPPORT=y
CONFIG_DEBUG=y

I have confirmed Zephyr RTOS detection and thread aware debugging works fine when building OpenOCD from source from https://github.com/zephyrproject-rtos/openocd.git @ zephyr-20191003, but fails when building from https://github.com/zephyrproject-rtos/openocd.git @ zephyr-20200116 (which appears to be the OpenOCD version included in 0.11.0).

Update:
I think we have narrowed down the issue to how the OS list is processed. Moving Zephyr higher in the list (openocd/src/rtos/rtos.c:43) enables Zephyr RTOS detection by OpenOCD.

Fails (zephyr-20200116):

static struct rtos_type *rtos_types[] = {
	&ThreadX_rtos,
	&FreeRTOS_rtos,
	&eCos_rtos,
	&Linux_os,
	&ChibiOS_rtos,
	&chromium_ec_rtos,
	&embKernel_rtos,
	&mqx_rtos,
	&uCOS_III_rtos,
	&nuttx_rtos,
	&hwthread_rtos,
	&Zephyr_rtos,
	NULL
};

Works (zephyr-20191003):

static struct rtos_type *rtos_types[] = {
	&ThreadX_rtos,
	&FreeRTOS_rtos,
	&eCos_rtos,
	&Linux_os,
	&ChibiOS_rtos,
	&chromium_ec_rtos,
	&embKernel_rtos,
	&mqx_rtos,
	&uCOS_III_rtos,
	&nuttx_rtos,
	&Zephyr_rtos,
	&hwthread_rtos,
	NULL
};

So the issue appears to be associated with RTOS list traversal.

What is the mearning for NG, PR, and CI?

Crosstool NG
What does NG represent for?
PR Builds
What does PR mean?
One the release is created, CI will build the SDK image and will upload it to the release page.
What does CI represent for?

Missing setjmp and longjmp in 32 bit libc for x86 (SDK 0.11.0)

It looks that symbols setjmp and longjmp are not defined in the 32bit version of libc.
As the result my project does not link properly (configured with CONFIG_NEWLIB_LIBC=y).

These symbols appear in the 64bit libc (as well as in all versions of ARM libraries).
Is it intentional?

hid@devel:/opt/zephyr-sdk$ nm -g x86_64-zephyr-elf/x86_64-zephyr-elf/lib/libc_nano.a | grep jmp
lib_a-setjmp.o:
0000000000000030 T longjmp
0000000000000000 T setjmp
hid@devel:/opt/zephyr-sdk$ nm -g x86_64-zephyr-elf/x86_64-zephyr-elf/lib/libc.a | grep jmp
lib_a-setjmp.o:
0000000000000030 T longjmp
0000000000000000 T setjmp
hid@devel:/opt/zephyr-sdk$ nm -g x86_64-zephyr-elf/x86_64-zephyr-elf/lib/32/libc.a | grep jmp
hid@devel:/opt/zephyr-sdk$ nm -g x86_64-zephyr-elf/x86_64-zephyr-elf/lib/32/libc_nano.a | grep jmp
hid@devel:/opt/zephyr-sdk$

when SDK installer is run by normal user, default install path should be wirtable by user

often users of the SDK run the installer as normal users but get the default install path as a system folder. When running as a normal user (no sudo) the default path should be user-writable.

arm64 alignment issue

Hi,

I am using 0.11.0-alpha-7 version (not the last one due to fp enablement)
Compiling to ARM64 cortex-a55 core.
And I got an alignment issue :

> 00000000000033a8 <_vfiprintf_r>:
>     33a8:	a9b27bfd 	stp	x29, x30, [sp, #-224]!
>     33ac:	910003fd 	mov	x29, sp
>     33b0:	a90153f3 	stp	x19, x20, [sp, #16]
>     33b4:	aa0103f4 	mov	x20, x1
>     33b8:	aa0203f3 	mov	x19, x2
>     33bc:	a9025bf5 	stp	x21, x22, [sp, #32]
>     33c0:	aa0003f5 	mov	x21, x0
>     33c4:	a90363f7 	stp	x23, x24, [sp, #48]
>     33c8:	aa0303f7 	mov	x23, x3
>     33cc:	a9046bf9 	stp	x25, x26, [sp, #64]
>     33d0:	f9002bfb 	str	x27, [sp, #80]
>     33d4:	b4000080 	cbz	x0, 33e4 <_vfiprintf_r+0x3c>
>     33d8:	b9405001 	ldr	w1, [x0, #80]
>     33dc:	35000041 	cbnz	w1, 33e4 <_vfiprintf_r+0x3c>
>     33e0:	94000a56 	bl	5d38 <__sinit>
>     33e4:	79402280 	ldrh	w0, [x20, #16]
>     33e8:	36180880 	tbz	w0, #3, 34f8 <_vfiprintf_r+0x150>
>     33ec:	f9400e80 	ldr	x0, [x20, #24]
>     33f0:	b4000840 	cbz	x0, 34f8 <_vfiprintf_r+0x150>
>     33f4:	52860400 	mov	w0, #0x3020                	// #12320
**>     33f8:	780993e0 	sturh	w0, [sp, #153]**

on the last line sturh w0, [sp, #153] I am getting alignment exception due to 153 offset

Can you suggest why?

Thanks,
Ehud

ARC toolchain support

Since the following commit crosstool-ng/crosstool-ng@62f5b90 it's possible to build multilibbed Elf32 (AKA baremetal) toolchain for ARC.

Latest Binutils (2.30), GCC (8.1.0) and GDB (8.1) are recommended to be used for ARC.
But given versions mentioned above are all available in up-to-date Crosstool-NG and moreover they are default versions now there should be no problem with it.

Soft-FP not supported on i586

The 0.9.5 SDK supported a soft-float multilib for i586. This isn't being built/supported with the 0.10.0-beta2 sdk.

error when running ARC GDB in SDK on Ubuntu 19.10

/opt/zephyr-sdk/arc-zephyr-elf/bin/arc-zephyr-elf-gdb: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory

Workaround:

 $ sudo apt install libpython2.7

Workstation setup instructions may need to be updated, or SDK build parameters adjusted.
I haven't tested whether this problem is specific to ARC's GDB in the SDK, or other platforms.

Need to unify release and tag names

We seem to use different "version" formats for file name, tag, etc. Need to clean this up so its the same everywhere.

sdk builds don't get published if we rebuild parts that fail

Since we publish the sdk builds to S3 based on build # we end up with files from the SDK build in different build # on S3. We should look to see if we use the SHA of the PR as the S3 part of the S3_PATH to handle such a case.

We also need to update ci-pipelines/shippable.jobs.yml to match any change.

Compile binutils with --enable-deterministic-archives

zephyrproject-rtos/zephyr@b4078c557ddcd7 has just been merged. Long story short it changes the ar invocation to pass -D which creates reproducible .a files by hardcoding the filemodes, timestamps and owners of the files inside the archive.

If no one/nothing complains about the change above after "some" time, a simpler way to achieve the same result is to flip the default when building the SDK. This is apparently possible with some --enable-deterministic-archives option in the binutils build. This what Debian has been doing for a long time (see discussion in https://salsa.debian.org/reproducible-builds/strip-nondeterminism/issues/3) and can be observed with /usr/bin/ar on any Ubuntu >= 18.04, maybe even earlier. I've seen rumours OpenSuSE didn't like it though, I haven't researched why.

qemu-sytem-x86_64 in Zephyr SDK 0.11.0 Alpha-8 fails to boot

The qemu-sytem-x86_64 included in the Zephyr SDK 0.11.0 Alpha-8 release fails to boot the Zephyr RTOS.

To reproduce this behaviour, point ZEPHYR_SDK_INSTALL_DIR to a Zephyr SDK 0.11.0 Alpha-8 installation and try running any tests/samples.

QEMU hangs after the Booting from ROM..:

[1/2] To exit from QEMU enter: 'CTRL+a, x'[QEMU] CPU: qemu64,+x2apic
qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21]
qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21]
SeaBIOS (version rel-1.12.1-0-ga5cab58-dirty-20191210_190318-6871e12d79fb-zephyr
)
Booting from ROM..

Last known working version is Zephyr SDK 0.11.0 Alpha-7.

Note that the QEMU version was bumped from 4.2.0-rc1 in the Alpha-7 to 4.2.0-rc4 in the Alpha-8.

v0.11.0 release per-arch downloads lack i586-zephyr-elf/i586-zephyr-elfiamcu toolchains

Thanks for providing split per-arch toolchain downloads in the SDK v0.11.0 release. As someone who suggested this feature, I'm eager to test it, but I don't see a dedicated toolchain for BOARD=qemu_x86. In 0.10.3, that was i586-zephyr-elf/ or i586-zephyr-elfiamcu/ target. I thought maybe zephyr-toolchain-x86_64-0.11.0-setup.run contains it (similarly to how riscv64 probably contains 32-bit support), but nope, there's only x86_64-zephyr-elf inside.

Doubled FLASH usage when using SDK 0.11.0-beta-1 (C++ app on Cortex-M)

I have a small C++ test application build for qemu_cortex_m3 board.
For SDK 0.10.3 FLASH usage is reported as about 28K where for SDK 0.11.0-beta-1 it is about 56K.

Is it expected beahviour?
Is it needed to add some config options to get better results?

There is used the same project configuration for both builds.
Zephyr updated (west update) as today (ff1cd6e10c156930e271017551e5b0befb0c0f42).

It seems that the newer GCC does great job for code size optimization for application but the net result is not great.

zephyr_10_3.map.txt
zephyr_11_0.map.txt

When I compare map files, then everything looks very nice until there is reached a part with sections like: .text.malloc_extend_top, .text._malloc_r, .text._svfprintf_r, .text._dtoa_r, .text._realloc_r etc.
Some of these symbols are not present in the "old" SDK and some have much smaller size i.e.
malloc_r: 172 vs. 1732 bytes, svfprintf_r: 916 vs. 6224 bytes, realloc_r: 76 vs. 1620 etc.

asm code fails on cortex-m23

There's a bug if we build for cortex-m23 with GNU as.

Reported upstream:

https://sourceware.org/bugzilla/show_bug.cgi?id=24559

Once fixed will backport to the SDK.

Failed to build zephyr-sdk (Error in MD5 checksums)

Hello, everyone!
I downloaded zephyr-sdk-0.10.3-setup.run, moved it to ubuntu18.04 in vmware, and then added mod x to it. Then I tried running it by ./zephyr-sdk-0.10.3-setup.run, but I got the following error:
Verifying archive integrity...Error in MD5 checksums: b1126471e95432b4ae5c3f27e0a4ba39 is different from 6fd9a58385305600e82c6caa5b23f218
How can I fix the error?
Thanks for any help!

build fails on MAC

bash-4 is needed

brew install bash help2man
git clone https://github.com/zephyrproject-rtos/sdk-ng.git
bash
export PATH=/usr/local/Cellar/binutils/2.31.1_2/bin:$PATH
./go.sh arm
/Volumes/CrossToolNGNew/crosstool-ng /Volumes/CrossToolNGNew
M config/arch/x86.in
M scripts/build/arch/x86.sh
HEAD is now at b82b8adb Merge pull request #984 from slash3g/master
INFO :: *** Generating package version descriptions
INFO :: Master packages: android-ndk autoconf automake avr-libc binutils cloog duma elf2flt expat gcc gdb gettext glibc-ports glibc gmp isl libelf libiconv libtool linux ltrace m4 make mingw-w64 mpc mpfr musl ncurses newlib strace uClibc zlib
INFO :: Generating 'config/versions/android-ndk.in'
INFO :: Generating 'config/versions/autoconf.in'
INFO :: Generating 'config/versions/automake.in'
INFO :: Generating 'config/versions/avr-libc.in'
INFO :: Generating 'config/versions/binutils.in'
INFO :: Generating 'config/versions/cloog.in'
.....
INFO :: Generating comp_libs.in (menu)
INFO :: *** Gathering the list of data files to install
INFO :: *** Running autoreconf
configure.ac:244: warning: macro 'AM_GNU_GETTEXT' not found in library
configure.ac:245: warning: macro 'AM_GNU_GETTEXT_VERSION' not found in library
INFO :: *** Done!
checking for a BSD-compatible install... /usr/local/bin/ginstall -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking how to create a pax tar archive... gnutar
checking whether to enable maintainer-specific portions of Makefiles... yes
checking build system type... x86_64-apple-darwin18.0.0
checking host system type... x86_64-apple-darwin18.0.0
checking whether ln -s works... yes
.......
checking for working ncurses/curses.h... no
checking for working ncurses.h... yes
checking for Curses Panel library with panel.h... yes
checking for Curses Menu library with menu.h... no
checking for Curses Menu library with ncurses/menu.h... no
configure: error: menu library not found
make: *** No targets specified and no makefile found. Stop.
/Volumes/CrossToolNGNew
Building arm
/Volumes/CrossToolNGNew/build/build_arm /Volumes/CrossToolNGNew/build
./go.sh: line 74: /Volumes/CrossToolNGNew/bin/ct-ng: No such file or directory
./go.sh: line 76: /Volumes/CrossToolNGNew/bin/ct-ng: No such file or directory
./go.sh: line 77: /Volumes/CrossToolNGNew/bin/ct-ng: No such file or directory
/Volumes/CrossToolNGNew/build
bash-4.4$

config.log attached
config.log

the arc gcc in zephyr sdk should be updated.

In ARC's secureshield, some new instrucitons are introduced, e.g., sflag, sjli. The current arc gcc (6.2.1 20160824) does not support these new instructions.

So suggest to update zhe arc gcc in zephyr-sdk to the latest version of arc gcc.

Add arm-generic-fdt machine support in qemu-system-aarch64

The arm-generic-fdt machine type is a special dts-based emulated hardware configuration mechanism for qemu-system-aarch64, currently available only in the Xilinx fork of qemu (https://github.com/xilinx/qemu).

This machine type is required to properly emulate Xilinx Zynq SoCs used by the qemu_cortex_r5 platform (the default hard-coded machine type xlnx-zcu102 available on the upstream qemu is incomplete and unusable).

In order to add arm-generic-fdt machine type support, the nativesdk-zephyr-qemu should be patched to include the changes made in the Xilinx fork. The latest common ancestor for Xilinx fork is the qemu release v4.1.0 in the master-next branch and this should be used to generate the patch.

For more details, see zephyrproject-rtos/zephyr#20217.

Build Fails on arm64 host

linaro@linaro-developer:~/zephyr/samples/basic/blinky/build$ cmake -DBOARD=96b_carbon ..
CMake Deprecation Warning at /home/linaro/zephyr/cmake/app/boilerplate.cmake:38 (cmake_policy):
  The OLD behavior for policy CMP0000 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.
Call Stack (most recent call first):
  CMakeLists.txt:1 (include)


-- Selected BOARD 96b_carbon
Zephyr version: 1.10.99
Parsing Kconfig tree in /home/linaro/zephyr/Kconfig
Using /home/linaro/zephyr/samples/basic/blinky/build/zephyr/.config as base
warning: HAS_DTS_SPI_DEVICE (defined at /home/linaro/zephyr/dts/Kconfig:38) has unsatisfied direct dependencies (HAS_DTS_SPI), but is currently being selected by the following symbols:
BOARD_96B_CARBON (defined at /home/linaro/zephyr/boards/arm/96b_carbon/Kconfig.board:8), with value y, direct dependencies SOC_STM32F401XE && <choice> (value: y), and select condition SOC_STM32F401XE && <choice> (value: y)
CMake Error at /home/linaro/zephyr/cmake/extensions.cmake:983 (message):
  No such file or directory: CMAKE_READELF: 'CMAKE_READELF-NOTFOUND'
Call Stack (most recent call first):
  /home/linaro/zephyr/cmake/compiler/gcc.cmake:14 (assert_exists)
  /home/linaro/zephyr/cmake/toolchain.cmake:38 (include)
  /home/linaro/zephyr/cmake/app/boilerplate.cmake:240 (include)
  CMakeLists.txt:1 (include)


-- Configuring incomplete, errors occurred!
linaro@linaro-developer:~/zephyr/samples/basic/blinky/build$

Debian Strech with updated cmake 3.9
the only issue with environment setup was that gcc-multilib wasn't installed.

Update GCC to some version supporting -mindirect-branch=thunk

This option has been added to GCC 8 and backported to GCC 7, and uses retpolines for both indirect jumps and calls. This is required to complement CONFIG_RETPOLINE, in order to mitigate against Spectre v2 for code written in C.

Zephyr SDK ships with very outdated newlib for Xtensa

I'm working on elaborating POSIX subsystem in Zephyr and unifying its support across different config options (different libc's, different archs, etc.) One particular idea is to make sure that minlibs contained the same internal (implementation) headers as newlib, so that higher-level, public POSIX headers can work interchangeably with either libc. One example of such a header is sys/_timeval.h, which defines struct timeval in newlib. After introducing and switching to such header for minlibc and switching to it in (initial version of) zephyrproject-rtos/zephyr#15628 , I got a failure with qemu_xtensa and newlib: https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/40119/5/tests .

Turns out, newlib for xtensa in SDK 0.10.0 doens't have that header. But it was introduced in 2015: https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=bb0159489785d577ad0b8061a1ba7956ee0f89d0 . That means that newlib as used by xtensa is very, very old.

Discrepancies like this make it very hard to go forward with POSIX subsystem development, as almost any change leads to failures from undermaintained architectures like xtensa.

SDK installer should propose to set path and variant in .zephyrrc, so user could start building instantly

At the end of installation, the SDK script should ask if we should store the location and variant in .zephyrrc to allow immediate use of the SDK.

Use SDK 0.11 for shippable

A lot of work currently being done on zephyr needs SDK 0.11. We need to use SDK 0.11 for shippable otherwise we get failures (see zephyrproject-rtos/zephyr#20263)

Cannot debug x86_64 qemu application with GDB

I'm trying to debug Zephyr application built for x86_64 QEMU with GDB but with no luck.

Zephyr application is built that way:

mkdir build
cd build
cmake -DBOARD=qemu_x86_64 ../samples/hello_world/
make
make run

Note make run step is necessary as otherwise produced Elf (./zephyr/zephyr.elf) won't be usable in QEMU.

Now start QEMU with GDB server (basically adding -S -s to normal QEMU invocation in make run):

$ZEPHYR_SDK_INSTALL_DIR/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-system-x86_64 -nographic -net none -pidfile qemu.pid -serial   mon:stdio -smp cpus=2 -kernel ./zephyr-qemu.elf -s -S

And finally connect with GDB to QEMU:

$ZEPHYR_SDK_INSTALL_DIR/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-system-x86_64 /x86_64-zephyr-elf/bin/x86_64-zephyr-elf-gdb zephyr-qemu.elf
...
Reading symbols from zephyr-qemu.elf...(no debugging symbols found)...done.

(gdb) target remote :1234
Remote debugging using :1234
warning: Selected architecture i386 is not compatible with reported target architecture i386:x86-64
warning: Architecture rejected target-supplied description
Remote 'g' packet reply is too long (expected 308 bytes, got 608 bytes): 0000000000000000000000000000000000000000000000006306000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
(gdb)

At this point nothing could be done like single-step etc.

Have PR builds placed somewhere

It would be nice that we can grab the build results from a PR to test.

bundled x86 assembler chokes on expressions involving division

GNU as normally supports arithmetic expressions on absolute symbols involving the / operator (for division), and on stock versions it works as expected. In the below text, the stock assembler versions of GNU as that I've tested that are not from the SDK: the system assembler on my Ubuntu dev system (which comes from binutils-2.30) and one source-built from binutils-2.32. The SDK assembler is any version of i586 and/or x86_64 that I've tested in the Zephyr SDK: I've specifically tested 0.9.5, 0.10.0 and 0.10.3.

Input file test.s:

X=(512/4)

movl $X, %eax

Run through the stock assembler with as -o test.o test.s, then objdump -d test.o and you get:

Disassembly of section .text:

0000000000000000 <.text>:
   0:   b8 80 00 00 00          mov    $0x80,%eax

Hex 0x80 being 128, which is indeed 512/4.

If you try to assemble with the SDK assembler, you'll get:

test.s: Assembler messages:
test.s:1: Error: found '
', expected: ')'

More troublingly, if you drop the parentheses from the expression so test.s is:

X=512/4

movl $X, %eax

Then the SDK assembler doesn't choke, it just silently produces the wrong results:

Disassembly of section .text:

0000000000000000 <.text>:
   0:   b8 00 02 00 00          mov    $0x200,%eax

Note the immediate constant 0x200 is 512. There was no division.

This problem appears limited to the / operator. Other operators that I've tried (*, >> etc.) work properly.

Edits: Speaking of silently ignoring input, markdown does that a lot. Fixed missing text by adding newlines where necessary. Ugh.

Modify scripts/make_zephyr_sdk.sh to support simplier x86_64 toolchain name

In scripts/make_zephyr_sdk.sh function parse_toolchain_name(), it looks at toolchain filenames to generate extraction command. However, it does not work if the x86_64 toolchain is simply named x86_64.tar.bz. This is due to the host tools file named zephyr-sdk-x86_64-hosttools-standalone-0.9.sh. The function would complain about having multiple toolchain for x86_64 since there are two files with x86_64 in their names. The script will need to modified to support a simple x86_64 name.

default libstdc++/libsupc++ should be 64-bit for x86_64

In SDK 0.10.3 & 0.11.0-alpha the x86_64-zephyr-elf/x86_64-zephyr-elf/libstdc++.a {libsupc++.a} should be a 64-bit target archive. For some reason its 32-bit.

This causes problems when trying to link or use cmake with c++.

ARM newlib contains unoptimised implementations

The newlib library included as part of the Zephyr SDK ARM toolchain contains unoptimised function implementations (e.g. memset, memcpy) that are normally used in the nano variant.

Since this newlib library is intended to be the full version (i.e. not nano), it should include the optimised function implementations, as the GNU ARM Embedded toolchain does.

This is especially important because the unoptimised implementations (in particular, memcpy) have been reported to be over 10 times slower than the optimised implementations, and this is simply an unacceptable level of performance.

Unoptimised memcpy implementation (gnuarmemb newlib nano / current Zephyr SDK newlib)

00000270 <memcpy>:
     270:	440a      	add	r2, r1
     272:	4291      	cmp	r1, r2
     274:	f100 33ff 	add.w	r3, r0, #4294967295	; 0xffffffff
     278:	d100      	bne.n	27c <memcpy+0xc>
     27a:	4770      	bx	lr
     27c:	b510      	push	{r4, lr}
     27e:	f811 4b01 	ldrb.w	r4, [r1], #1
     282:	4291      	cmp	r1, r2
     284:	f803 4f01 	strb.w	r4, [r3, #1]!
     288:	d1f9      	bne.n	27e <memcpy+0xe>
     28a:	bd10      	pop	{r4, pc}

Optimised memcpy implementation (gnuarmemb newlib full / should be Zephyr SDK newlib)

000000ec <memcpy>:
      ec:	4684      	mov	ip, r0
      ee:	ea41 0300 	orr.w	r3, r1, r0
      f2:	f013 0303 	ands.w	r3, r3, #3
      f6:	d149      	bne.n	18c <_STRUCT_KERNEL_SIZE+0x64>
      f8:	3a40      	subs	r2, #64	; 0x40
      fa:	d323      	bcc.n	144 <_STRUCT_KERNEL_SIZE+0x1c>
      fc:	680b      	ldr	r3, [r1, #0]
      fe:	6003      	str	r3, [r0, #0]
     100:	684b      	ldr	r3, [r1, #4]
     102:	6043      	str	r3, [r0, #4]
     104:	688b      	ldr	r3, [r1, #8]
     106:	6083      	str	r3, [r0, #8]
     108:	68cb      	ldr	r3, [r1, #12]
     10a:	60c3      	str	r3, [r0, #12]
     10c:	690b      	ldr	r3, [r1, #16]
     10e:	6103      	str	r3, [r0, #16]
     110:	694b      	ldr	r3, [r1, #20]
     112:	6143      	str	r3, [r0, #20]
     114:	698b      	ldr	r3, [r1, #24]
     116:	6183      	str	r3, [r0, #24]
     118:	69cb      	ldr	r3, [r1, #28]
     11a:	61c3      	str	r3, [r0, #28]
     11c:	6a0b      	ldr	r3, [r1, #32]
     11e:	6203      	str	r3, [r0, #32]
     120:	6a4b      	ldr	r3, [r1, #36]	; 0x24
     122:	6243      	str	r3, [r0, #36]	; 0x24
     124:	6a8b      	ldr	r3, [r1, #40]	; 0x28
     126:	6283      	str	r3, [r0, #40]	; 0x28
     128:	6acb      	ldr	r3, [r1, #44]	; 0x2c
     12a:	62c3      	str	r3, [r0, #44]	; 0x2c
     12c:	6b0b      	ldr	r3, [r1, #48]	; 0x30
     12e:	6303      	str	r3, [r0, #48]	; 0x30
     130:	6b4b      	ldr	r3, [r1, #52]	; 0x34
     132:	6343      	str	r3, [r0, #52]	; 0x34
     134:	6b8b      	ldr	r3, [r1, #56]	; 0x38
     136:	6383      	str	r3, [r0, #56]	; 0x38
     138:	6bcb      	ldr	r3, [r1, #60]	; 0x3c
     13a:	63c3      	str	r3, [r0, #60]	; 0x3c
     13c:	3040      	adds	r0, #64	; 0x40
     13e:	3140      	adds	r1, #64	; 0x40
     140:	3a40      	subs	r2, #64	; 0x40
     142:	d2db      	bcs.n	fc <memcpy+0x10>
     144:	3230      	adds	r2, #48	; 0x30
     146:	d30b      	bcc.n	160 <_STRUCT_KERNEL_SIZE+0x38>
     148:	680b      	ldr	r3, [r1, #0]
     14a:	6003      	str	r3, [r0, #0]
     14c:	684b      	ldr	r3, [r1, #4]
     14e:	6043      	str	r3, [r0, #4]
     150:	688b      	ldr	r3, [r1, #8]
     152:	6083      	str	r3, [r0, #8]
     154:	68cb      	ldr	r3, [r1, #12]
     156:	60c3      	str	r3, [r0, #12]
     158:	3010      	adds	r0, #16
     15a:	3110      	adds	r1, #16
     15c:	3a10      	subs	r2, #16
     15e:	d2f3      	bcs.n	148 <_STRUCT_KERNEL_SIZE+0x20>
     160:	320c      	adds	r2, #12
     162:	d305      	bcc.n	170 <_STRUCT_KERNEL_SIZE+0x48>
     164:	f851 3b04 	ldr.w	r3, [r1], #4
     168:	f840 3b04 	str.w	r3, [r0], #4
     16c:	3a04      	subs	r2, #4
     16e:	d2f9      	bcs.n	164 <_STRUCT_KERNEL_SIZE+0x3c>
     170:	3204      	adds	r2, #4
     172:	d008      	beq.n	186 <_STRUCT_KERNEL_SIZE+0x5e>
     174:	07d2      	lsls	r2, r2, #31
     176:	bf1c      	itt	ne
     178:	f811 3b01 	ldrbne.w	r3, [r1], #1
     17c:	f800 3b01 	strbne.w	r3, [r0], #1
     180:	d301      	bcc.n	186 <_STRUCT_KERNEL_SIZE+0x5e>
     182:	880b      	ldrh	r3, [r1, #0]
     184:	8003      	strh	r3, [r0, #0]
     186:	4660      	mov	r0, ip
     188:	4770      	bx	lr
     18a:	bf00      	nop
     18c:	2a08      	cmp	r2, #8
     18e:	d313      	bcc.n	1b8 <_STRUCT_KERNEL_SIZE+0x90>
     190:	078b      	lsls	r3, r1, #30
     192:	d0b1      	beq.n	f8 <memcpy+0xc>
     194:	f010 0303 	ands.w	r3, r0, #3
     198:	d0ae      	beq.n	f8 <memcpy+0xc>
     19a:	f1c3 0304 	rsb	r3, r3, #4
     19e:	1ad2      	subs	r2, r2, r3
     1a0:	07db      	lsls	r3, r3, #31
     1a2:	bf1c      	itt	ne
     1a4:	f811 3b01 	ldrbne.w	r3, [r1], #1
     1a8:	f800 3b01 	strbne.w	r3, [r0], #1
     1ac:	d3a4      	bcc.n	f8 <memcpy+0xc>
     1ae:	f831 3b02 	ldrh.w	r3, [r1], #2
     1b2:	f820 3b02 	strh.w	r3, [r0], #2
     1b6:	e79f      	b.n	f8 <memcpy+0xc>
     1b8:	3a04      	subs	r2, #4
     1ba:	d3d9      	bcc.n	170 <_STRUCT_KERNEL_SIZE+0x48>
     1bc:	3a01      	subs	r2, #1
     1be:	f811 3b01 	ldrb.w	r3, [r1], #1
     1c2:	f800 3b01 	strb.w	r3, [r0], #1
     1c6:	d2f9      	bcs.n	1bc <_STRUCT_KERNEL_SIZE+0x94>
     1c8:	780b      	ldrb	r3, [r1, #0]
     1ca:	7003      	strb	r3, [r0, #0]
     1cc:	784b      	ldrb	r3, [r1, #1]
     1ce:	7043      	strb	r3, [r0, #1]
     1d0:	788b      	ldrb	r3, [r1, #2]
     1d2:	7083      	strb	r3, [r0, #2]
     1d4:	4660      	mov	r0, ip
     1d6:	4770      	bx	lr

A further investigation into this issue is required.

This does not look like a tar archive

On centos , it can't uncompress SDK

 [|] Installing x86 tools...tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
�����������������������������[/] Installing x86 tools...����������������������������� [-] Installing x86 tools...����������������������������� [\] Installing x86 tools...tar: Error exit delayed from previous errors
�����������������������������[*] Installing x86 tools... ����
[|] Installing arm tools...tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
���������������������������[-] Installing arm tools...����������������������������� [\] Installing arm tools...����������������������������� [|] Installing arm tools...����������������������������� [/] Installing arm tools...����������������������������� [-] Installing arm tools...����������������������������� [\] Installing arm tools...����������������������������� [|] Installing arm tools...����������������������������� [/] Installing arm tools...����������������������������� [-] Installing arm tools...����������������������������� [\] Installing arm tools...����������������������������� [|] Installing arm tools...tar: Error exit delayed from previous errors
�����������������������������[*] Installing arm tools... ����
[|] Installing arc tools...tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers

I modify the command parameter -xf to -jxvf in setup.sh