epasveer
Instructions needed for arm-eabi
I am trying to debug an Ada firmware using Black Magic Probe as an SWD Debugger with GDB Server. Unfortunately, I am unable to configure it to for seer. I'm fairly new to GDB and it's confusing, requiring a deep understanding of its internals. There are two parts to the configuration, the probe and toolchain.
The probe requires configuring GDB to use the probe using remote server. The instructions I'm using can be found on the BMP site.
The second part requires configuring arm-eabi-gdb which is supplied by Ada's toolchain and installed by Alire on a per project basis. I don't know the reason it's named that--it's usually arm-none-eabi-gdb. It's located in a directory containing ARM specific Ada toolchain. In the seer main configuration, it says it requires MI. I have no idea what it is and if arm-eabi-gdb even supports it.
The link mentions to use this as the gdb program. As a test, try manually running it with the MI argument from the command line.
$ arm-none-eabi-gdb --interpreter=mi
If it accepts it, then it should be good to go. If it doesn't like it, then Seer won't work.
The link also mentions how to connect to the device while in gdb.
(gdb) target extended-remote /dev/ttyACM0
For Seer, this translates to running Seer this way:
$ seer --connect /dev/ttyACM0
If you need to load in a symbol file (for the program's debug information), then add this:
$ seer --connect /dev/ttyACM0 --sym programs.elf # Add the program's elf file to load debug info.
Hope this helps. It really depends on the first point working, though.
When I did a make install, it installed "seergdb", not "seer." Anyway, no luck. When I run the following command:
% seergdb --connect /dev/cu.usbmodem14101 --sym bin/main
I get the following message:
"Unable to launch the GDB program.
(/usr/bin/gdb --interpreter=mi)
Error status=0)
% seergdb --connect /dev/cu.usbmodem14101 --sym bin/main
OK. I had to manually set the path to /usr/local/bin/arm-none-eabi-gdb and it finally work. I now get another error when I try to step into a line of code:
Cannot find bounds of current function.
Hi,
I had to manually set the path
Odd. Before you mentioned using an environment variable for the location of gdb. Can you tell me the variable you used? And its value? Also, what did you set in the gdb config dialog for the path to gdb?
If you didn't use environment variables, then you would need to set the full path to gdb if /usr/local/bin/ isn't in your $path variable. Use this to see if /usr/local/bin is in your default path.
% echo $path
Cannot find bounds of current function.
I suspect you're viewing the assembly tab? This message happens if the program being debugged is written in assembly, or if there's no debug information. I see you used the --sym flag. Does bin/main have debug information turned on?
bin/main seems like an odd name for a symbol file. Usually the name ends with .elf.
You can set Seer to examine N number of instructions when viewing the Assembly tab. Set Length in the Disassembly Mode field.
Hi,
I am not debugging my code in assembly. Here's what I see when I use the file command:
% file bin/main
bin/main: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked,
with debug_info, not stripped
I didn't see a separate symbol file as I am normally accustomed to. I assume it's embedded in the executable. The only reason I included it as the --sym argument was to follow your example and because seergdb complains the executable name can't be provided for 'connect' mode. How does it determine what executable to debug?
According to some suggestions on the Ada forum, it's recommended you run GDB from the same toolchain used to build your executable. Does GDB require a specialized build depending on every architecture, runtime, and OS in order for it to work? The toolchain path is in an environment variable set by Alire. Below is the full path and its contents:
GNAT_ARM_ELF_ALIRE_PREFIX=/Users/Joe/.config/alire/cache/dependencies/gnat_arm_elf_12.2.1_f4bfd822/bin
arm-eabi-addr2line arm-eabi-gcc-ranlib arm-eabi-gnatkr arm-eabi-nm
arm-eabi-ar arm-eabi-gcov arm-eabi-gnatlink arm-eabi-objcopy
arm-eabi-as arm-eabi-gcov-dump arm-eabi-gnatls arm-eabi-objdump
arm-eabi-c++filt arm-eabi-gcov-tool arm-eabi-gnatmake arm-eabi-ranlib
arm-eabi-cpp arm-eabi-gdb arm-eabi-gnatname arm-eabi-readelf
arm-eabi-elfedit arm-eabi-gdb-add-index arm-eabi-gnatprep arm-eabi-size
arm-eabi-gcc arm-eabi-gnat arm-eabi-gprof arm-eabi-strings
arm-eabi-gcc-12.2.0 arm-eabi-gnatbind arm-eabi-ld arm-eabi-strip
arm-eabi-gcc-ar arm-eabi-gnatchop arm-eabi-ld.bfd
arm-eabi-gcc-nm arm-eabi-gnatclean arm-eabi-lto-dump
When I try to set up my environment to use the toolchain path's arm-eabi-gdb, all hell breaks loose. It simply doesn't work because it doesn't support interpreter=mi option. When I run it from the command line, it shows the source for main, but throws an exception as soon as I try to execute through the code.
I finally got seergdb to start up and show the source for the main function by pasting /usr/local/bin/arm-none-eabi-gdb into the configuration dialog, but I can't step into any subprograms. Interestingly, seergdb's configuration dialog doesn't save the value.
As far as the name, I use main without the elf suffix since it's the convention I picked up from Ada sample programs. Should I add .ELF? Will it make a difference?
I've enclosed an archive of the executable and a generated symbol file if you think it might be helpful.
My immediate guess is that the arm-eabi-gdb is broken for some reason.
Hi Joe,
I think Seer working or failing with this hinges on running this command to see if the arm gdb accepts the "mi" option.
$ /usr/local/bin/arm-none-eabi-gdb --interpreter=mi
What does the above command output when you enter it at the command prompt?
I'll see if I can install "arm-none-eabi-gdb" on my machine.
What version are you using?
$ /usr/local/bin/arm-none-eabi-gdb --version
Below, I've included the output of the commands you requested.
I'm trying to figure out the source of the problem. We can forget about arm-eabi-gdb for now since it doesn't support MI and crashes as soon as I step into a subprogram. arm-none-eabi-gdb, however, works with all the functionality except for stepping into subprograms. Could it be that it requires a special build to support Ada's conventions? At the lowest level, Ada's calling architecture is different from C/C++, so I wouldn't be surprised if it requires a special build of GDB for Ada support.
% /usr/local/bin/arm-none-eabi-gdb --interpreter=mi
=thread-group-added,id="i1"
~"GNU gdb (Arm GNU Toolchain 12.2.Rel1 (Build arm-12.24)) 12.1.90.20221210-git\n"
~"Copyright (C) 2022 Free Software Foundation, Inc.\n"
~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law."
~"\nType \"show copying\" and \"show warranty\" for details.\n"
~"This GDB was configured as \"--host=x86_64-apple-darwin19.6.0 --target=arm-none-eabi\".\n"
~"Type \"show configuration\" for configuration details.\n"
~"For bug reporting instructions, please see:\n"
~"<https://bugs.linaro.org/>.\n"
~"Find the GDB manual and other documentation resources online at:\n <http://www.gnu.org/software/gdb/documentation/>."
~"\n\n"
~"For help, type \"help\".\n"
~"Type \"apropos word\" to search for commands related to \"word\".\n"
(gdb)
GNU gdb (Arm GNU Toolchain 12.2.Rel1 (Build arm-12.24)) 12.1.90.20221210-git
Copyright (C) 2022 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.
Did you have any luck stepping through the code? Is there anything you need? Thanks.
Hi,
works with all the functionality except for stepping into subprograms.
Took me awhile to figure out what subprograms are. Basically, Ada speak for functions, or subroutines. :^)
So I have a test Ada program that I used to check if Seer supports debugging Ada programs. I modified it to use subprograms
https://github.com/epasveer/seer/tree/main/tests/helloada
I added a README.build file to mimic the "can't step into subprograms".
$ gnatmake -c --GCC=/usr/bin/gcc-7 -O3 increment_by.adb
$ gnatmake -c --GCC=/usr/bin/gcc-7 -g helloada.adb
$ gnatmake -b --GCC=/usr/bin/gcc-7 -g helloada.adb
$ gnatlink helloada
Note, all this is on Linux and I'm no Ada expert. Especially with the gnatmake tool.
helloada.adb is the main procedure. increment_by.adb is a simple subprogram.
With the steps in the README.build file, you can see I'm compiling increment_by.adb with debug turned off (-O). The main procedure has debug enabled (-g).
After binding/linking, debugging the program will show the code in the main procedure. But attempting to step into the increment_by subprogram doesn't happen (because it wasn't compiled with debug enabled).
Running the file command on the executable does show debug information is present. However, if you can run file on the intermediate object files, you can confirm if the subprograms are being compiled with debug enabled.
$ file helloada helloada.o increment_by.o
helloada: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=dfc77b85b759a22a42ddaa75c050d4458b3175a4, for GNU/Linux 3.2.0, with debug_info, not stripped
helloada.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped
increment_by.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
Compiling the increment_by subprogram with debug will allow Seer to step into that subprogram.
Anyway, something to verify with your subprograms.
Hi.
Just seeing if my suggestion to compile/link your program with debug info turned on has worked. Otherwise, I'll close the task.
Thanks,