How to use the xPack GNU AArch64 Embedded GCC
This page is intended for those who plan to use the xPack GNU AArch64 Embedded GCC binaries in their workflows.
Versioning
The version string used by the
upstream Arm GNU Toolchain project is a bit unusual and unstable in time,
(like 13.3.Rel1)
therefore the upstream GCC version is prefered, which
is a three number string
like 13.3.1-1.1;
to this string the xPack distribution adds a fourth number that represents
the Arm release with the same GCC release, and a fifth number
that represents the xPack release of the same Arm release;
since SemVer allows only three numbers,
all additional ones can
be added only as pre-release strings, separated by a dash,
like 13.3.1-1.1-1.1. When
published as a npm package, the version gets
a sixth number,
like 13.3.1-1.1.2.
Since adherence of third party packages to SemVer is not guaranteed,
it is recommended to avoid referring to the xPack GNU AArch64 Embedded GCC dependency via
a SemVer expressions
like ^13.3.1-1.1 or ~13.3.1-1.1, and
prefer exact matches,
like 13.3.1-1.1.2.
Shared libraries
On all platforms the binary xPack packages are standalone, and expect only the standard runtime to be present on the host.
All dependencies that are built as shared libraries are copied locally
in the libexec folder (or in the same folder as the executable for Windows).
DT_RPATH and LD_LIBRARY_PATH
On GNU/Linux the binaries are adjusted to use a relative path:
$ readelf -d library.so | grep rpath
0x000000000000001d (RPATH) Library rpath: [$ORIGIN]
In the GNU ld.so search strategy, the DT_RPATH has
the highest priority, higher than LD_LIBRARY_PATH, so if this latter one
is set in the environment, it should not interfere with the xPack binaries.
Please note that previous versions, up to mid-2020, used DT_RUNPATH, which
has a priority lower than LD_LIBRARY_PATH; setting LD_LIBRARY_PATH
in the environment overrode DT_RUNPATH, resulting in failures to load
the libraries.
@rpath and @loader_path
Similarly, on macOS, the binaries are adjusted with install_name_tool
(part of CLT) to use a relative path.
Miscellaneous
XML parsing in GDB
Some advanced GDB servers, like the one provided with SEGGER J-Link, are capable of passing an XML with the target capabilities to the GDB client. For unknown reasons, the Arm toolchain distribution came without XML parsing support. The xPack distribution brings back support for XML parsing and full integration with the SEGGER J-Link GDB server.
Python
Support for Python scripting was added to GDB. This distribution provides
a separate binary, aarch64-none-elf-gdb-py3 with
support for Python .
The Python 3 run-time is included, so GDB does not need any version of Python to be installed, and is insensitive to the presence of other versions.
Text User Interface (TUI)
Support for TUI was added to GDB. The ncurses library was added to
the distribution.
TUI is not available on Windows
No Guile
Due to the difficulties of building standalone Guile libraries on all platforms, support for Guile scripting in GDB is currently not available.
Using aarch64-none-elf-gcc in testing
TODO