I'm seeing a segmentation fault in gcc-arm-none-eabi-8-2018-q4-major when I try to debug a binary written in Rust (it's actually the TockOS kernel).
Rust is actually using LLVM nightly to generate the binary. I wonder if that's causing issues.
I'd gladly upload the .elf file here but the server is giving me a 500 error message
This is the repository: https://github.com/dc740/tock
It will auto-download all the required tools to compile as long as rustup command is installed and available
Here is how I'm running gdb
~/CIAA/gcc-arm-none-eabi-8-2018-q4-major/bin/arm-none-eabi-gdb target/thumbv7em-none-eabi/release/edu-ciaa.elf -x gdb_from_commandline_startup_commands
GNU gdb (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 220.127.116.1181213-git
Copyright (C) 2018 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-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:
For help, type "help".
Type "apropos word" to search for commands related to "word"...
/home/dc740/.gdbinit:1582: Error in sourced command file:
Scripting in the "Python" language is not supported in this copy of GDB.
Reading symbols from target/thumbv7em-none-eabi/release/edu-ciaa.elf...
Segmentation fault (core dumped)
Loading the .elf works fine. Apparently the segmentation fault appears when I try to connect to the openocd instance
OpenOCD is running like this
openocd -c "gdb_port 3333" -c "telnet_port 4444" -c "tcl_port 6666" -f ftdi_lpc4337.cfg
and the gdb commands I'm running to connect to it are:
target remote localhost:3333set mem inaccessible-by-default offmonitor arm semihosting enablemonitor halt
I also tried to use gcc-arm-none-eabi-7-2018-q2-update and to my surprise this version works almost OK.
I'm getting a lot of these errors
warning: (Internal error: pc 0x1a00350c in read in psymtab, but not in symtab.)
I'm fully aware that these are all bugs in the toolchain, but I was wondering if anyone could give me a hint on how to workaround them, or help getting them fixed, since they are immensely blocking my progress.
This error message "Scripting in the "Python" language is not supported in this copy of GDB." shows that your GDB don't have python scripting support.
This below change works :
--- aarch64--glibc--bleeding-edge-2017.11-1.defconfig.orig 2018-02-20 17:28:52.567018000 -0800
+++ aarch64--glibc--bleeding-edge-2017.11-1.defconfig 2018-02-20 17:28:56.780343000 -0800
@@ -8,6 +8,7 @@
# BR2_PACKAGE_BUSYBOX is not set
For details, please refer to https://github.com/bootlin/toolchains-builder/issues/5
The background to disable python by default is mentioned here https://answers.launchpad.net/gcc-arm-embedded/+question/218684:
"The reason to disable python support in GDB is to avoid lib dependence on Python. So the released tool chain can work on more platforms like RHEL4. If you need such support, I think you can rebuild gdb with proper configure option. The build of gdb is pretty independent and can be accomplished in a short time. The tool chain source package and build manual are all in this website, you can start from them."
Thank you but, I'm asking about the segmentation fault. I don't care about python support at all.
`gcc-arm-none-eabi-7-2018-q2-update` works kind of OK, and it also doesn't have python support. So, your answer is not related to the segmentation fault question.
As I understand your issue:
* When compiling using llvm, GDB segfaults
* When compiling using GCC, GDB produces lots of psymtab warnings, but you can then still debug the binary.
For the segfault, it would be useful to know why GDB segfaulted.
Are you able to build arm-none-eabi-gdb from the source? If so, I can give you instructions for building it with symbols enabled. We can then look at the core dump generated by GDB to get a backtrace at the point it died. This might tell us something useful.
The psymtab error sounds like your binary isn't being created correctly - everything in psymtab really should also be in symtab. See https://docs.freebsd.org/info/gdbint/gdbint.info.Partial_Symbol_Tables.html for a quick description of why. The binary should run fine without the symbols, which is why it works when you run it by itself. It's just GDB that needs the symbols. Reporting a bug on the GCC bugzilla might be the best option. You might be able to use objdump and/or nm to find out which symbols are missing.
View all questions in GNU Toolchain forum