gcc-arm-none-eabi-8: GDB segmentation fault

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

cd boards/ciaa/edu-ciaa
make
~/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) 8.2.50.20181213-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:
<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"...
/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:3333
set mem inaccessible-by-default off
monitor arm semihosting enable
monitor 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.

Parents
  • 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.

Reply
  • 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.

Children
No data
More questions in this forum