I'm compiling and running a bare metal AArch64 bootloader using 3 different compilers: the Linaro / ARM GCC 10.3.1 compiler, the Linaro / ARM GCC 10.2.1 compiler, and an in-house built GCC 10.2.0 compiler.
GDB will single step using the either of the GCC 10.2 compilers; but runs without halting when step is requested - or perhaps steps multiple instructions - when built using the Linaro / ARM-supplied GCC 10.3.1.
Eclipse CDT (v4.20 aka 2021-06) is able to correlate debugging information from binaries built with either of the gcc 10.2 toolchains, and to single step correctly through the program. Breakpoints work as expected. Registers display fine.
Eclipse CDT is not able to correlate current PC location to source code using the binary built with Linaro / ARM 10.3, instead bringing up a disassembly window. Breakpoints placed at assembly instructions in the editor do not work.
I've tried three different GDB versions - ARM's supplied 10.2 and 10.3 GDB, and the in-house built GDB. Results are the same.
The same makefile is used to create the binaries, with just a few macro definitions to switch. The only compiler flag of interest is -march=armv8.2-a (and of course -g -O0). -mtune=cortex-a53 doesn't help.
The board is connected via JTAG using OpenOCD 0.11.0+ and an Olimex ARM-USB-OCD-H adapter.
I'm building in a cygwin shell on Windows 10 version 21H1 using the compilers:
gcc-arm-10.3-2021.07-mingw-w64-i686-aarch64-none-elf.tar.xz gcc-arm-10.2-2020.11-mingw-w64-i686-aarch64-none-elf.tar.xz
downloaded from:
https://developer.arm.com/tools-and-software/open-source-software/developer-...
Differences in compiler configuration (gcc -v) are:
Failing - Linaro / ARM GCC 10.3(.1):
--enable-checking=release --target=aarch64-none-elf --with-libiconv-prefix=/data/jenkins/workspace/GNU-toolchain/arm-10-4/build-mingw-aarch64-none-elf/host-tools
Working - in house GCC 10.2.1:
--build=x86_64-w64-mingw32 --disable-libffi --disable-libgomp --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --disable-lto --disable-win32-registry --enable-multilib --target=aarch64-elf --with-gcc --with-gnu-as --with-gnu-ld --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-multilib-list=lp64,ilp32 --with-stabs --with-sysroot=/build/aarch64-elf_10.2.0/cross-gcc/aarch64-elf --with-zstd=/build/aarch64-elf_10.2.0/host
Has anyone been able to perform hardware debugging of binaries built with the latest 10.3 builds using GDB (and maybe even Eclipse CDT)?
Any suggestions as to other steps to try?
Thanks.
Hi,
On 8/9/21 1:44 PM, Dietmar May wrote:
I'm compiling and running a bare metal AArch64 bootloader using 3 different compilers: the Linaro / ARM GCC 10.3.1 compiler, the Linaro / ARM GCC 10.2.1 compiler, and an in-house built GCC 10.2.0 compiler.
GDB will single step using the either of the GCC 10.2 compilers; but runs without halting when step is requested - or perhaps steps multiple instructions - when built using the Linaro / ARM-supplied GCC 10.3.1.
Could you please capture a remote log (I'm assuming GDB is connected remotely to OpenOCD) for the sessions with binaries built with 10.2 and 10.3?
You can do so by entering "set remotelogfile <path_to_log_file>" in GDB's console and then proceeding with the debugging session.
Enabling standard logging with "set logging on" would also be helpful.
Based on the logs, we can have a better idea of what's going on.
Regards, Luis
Eclipse CDT (v4.20 aka 2021-06) is able to correlate debugging information from binaries built with either of the gcc 10.2 toolchains, and to single step correctly through the program. Breakpoints work as expected. Registers display fine.
Eclipse CDT is not able to correlate current PC location to source code using the binary built with Linaro / ARM 10.3, instead bringing up a disassembly window. Breakpoints placed at assembly instructions in the editor do not work.
I've tried three different GDB versions - ARM's supplied 10.2 and 10.3 GDB, and the in-house built GDB. Results are the same.
The same makefile is used to create the binaries, with just a few macro definitions to switch. The only compiler flag of interest is -march=armv8.2-a (and of course -g -O0). -mtune=cortex-a53 doesn't help.
The board is connected via JTAG using OpenOCD 0.11.0+ and an Olimex ARM-USB-OCD-H adapter.
I'm building in a cygwin shell on Windows 10 version 21H1 using the compilers:
gcc-arm-10.3-2021.07-mingw-w64-i686-aarch64-none-elf.tar.xz gcc-arm-10.2-2020.11-mingw-w64-i686-aarch64-none-elf.tar.xz
downloaded from:
https://developer.arm.com/tools-and-software/open-source-software/developer-...
Differences in compiler configuration (gcc -v) are:
Failing - Linaro / ARM GCC 10.3(.1):
--enable-checking=release --target=aarch64-none-elf --with-libiconv-prefix=/data/jenkins/workspace/GNU-toolchain/arm-10-4/build-mingw-aarch64-none-elf/host-tools
Working - in house GCC 10.2.1:
--build=x86_64-w64-mingw32 --disable-libffi --disable-libgomp --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --disable-lto --disable-win32-registry --enable-multilib --target=aarch64-elf --with-gcc --with-gnu-as --with-gnu-ld --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-multilib-list=lp64,ilp32 --with-stabs --with-sysroot=/build/aarch64-elf_10.2.0/cross-gcc/aarch64-elf --with-zstd=/build/aarch64-elf_10.2.0/host
Has anyone been able to perform hardware debugging of binaries built with the latest 10.3 builds using GDB (and maybe even Eclipse CDT)?
Any suggestions as to other steps to try?
Thanks. _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
linaro-toolchain@lists.linaro.org
-
Dietmar May -
Luis Machado