Give symbol file to GDB after connecting about seer

[hrw]

Issue #216 shows my start setup.

[epasveer]

I agree. I'll debug it to see why it's happening.

[epasveer]

It's this line that I'm focusing on.

warning: No executable has been specified and target does not support determining executable automatically.
Try using the \"file\" command.

It suggests some command was given to gdb but gdb isn't in the right state. No program has been loaded. I suspect by the gdbstub.

It looks like you got things working, albeit, with some kludges. I'll come back to this task after I learn more about your environment.

I'm going to go on to tasks #192 and #194.

[hrw]

As symbol file is now loaded this issue can be closed.

Thanks for making Seer!

[epasveer]

Noted. This can be fixed. I ran into the same problem yesterday working on this task #6.

[epasveer]

BTW, with task #6, the user does a "load" command from gdb's command prompt after connecting. Do you do the same?

I can build this into the "connect" dialog.

[hrw]

I am fine with adding 'add-symbol-file' into 'GDB commands after connect'. But I also think that I should not have to do it as this is duplication.

[epasveer]

I'm curious why you use 'add-symbol-file' and not 'symbol-file'. Does it matter?

[hrw]

I am not good at gdb. 'add-symbol-file' was a command I found in some how to. It works so didn't bothered looking elsewhere.

[epasveer]

okay. I'll try it both ways.

[epasveer]

A couple questions.

Are you connecting to a gdbserver? Is so, can you:

1. Provide the full command you use to launch the gdbserver.
2. Provide the version of gdbserver ($ gdbserver --version)

From your screenshots, it looks like you are using gdb version 14.1. But to confirm:

1. Provide the version of gdb ($ gdb --version)

Thanks.

[hrw]

I am connecting to QEMU which runs gdbserver on TCP port 1234.

My QEMU run uses 'boot-sbsa-ref.sh' script from my sbsa-ref-status repo using firmware files which are stored in repo in compressed form:

 $  ./boot-sbsa-ref.sh --gdb --cpu=max --no-its
QEMU emulator version 8.2.50 (v8.2.0-198-gfffb986705-dirty)
Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers

QEMU command line arguments:

-machine sbsa-ref
-cpu max
-drive file=fat:rw:/home/marcin/devel/linaro/sbsa-qemu/sbsa-ref-status/disks/virtual/,format=raw
-drive format=raw,file=/home/marcin/devel/linaro/sbsa-qemu/sbsa-ref-status/disks/full-debian.hddimg
-display gtk
-device usb-kbd
-device usb-tablet
-device usb-mouse
-watchdog-action none
-monitor telnet::45454,server,nowait
-serial stdio
--no-reboot
-s
-S
-nographic
-m 4G
-smp 8,sockets=2,clusters=2,cores=1,threads=2
-drive if=pflash,file=firmware/SBSA_FLASH0.fd,format=raw
-drive if=pflash,file=firmware/SBSA_FLASH1.fd,format=raw

 $  gdbserver --version
GNU gdbserver (Fedora Linux) 14.1-1.fc39
Copyright (C) 2023 Free Software Foundation, Inc.
gdbserver is free software, covered by the GNU General Public License.
This gdbserver was configured as "x86_64-redhat-linux-gnu"
 $  gdb --version
GNU gdb (Fedora Linux) 14.1-1.fc39
Copyright (C) 2023 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.

Both from Fedora 39.

[epasveer]

I was hoping to clone your repo and duplicate the problem. I suspect I'm missing some stuff :^)

erniep@gracie:(sbsa-ref-status)$ ./boot-sbsa-ref.sh --gdb --cpu=max --no-its
./boot-sbsa-ref.sh: line 352: ../code/qemu/build/aarch64-softmmu/qemu-system-aarch64: No such file or directory

QEMU command line arguments:

-machine sbsa-ref
-cpu max
-drive file=fat:rw:/nas/erniep/Development/sbsa-ref-status/sbsa-ref-status/disks/virtual/,format=raw
-drive format=raw,file=/nas/erniep/Development/sbsa-ref-status/sbsa-ref-status/disks/full-debian.hddimg
-device usb-kbd
-device usb-tablet
-device usb-mouse
-watchdog-action none
-monitor telnet::45454,server,nowait
-serial stdio
--no-reboot
-s
-S
-nographic
-m 4G
-smp 4
-drive if=pflash,file=firmware/SBSA_FLASH0.fd,format=raw
-drive if=pflash,file=firmware/SBSA_FLASH1.fd,format=raw

./boot-sbsa-ref.sh: line 359: ../code/qemu/build/aarch64-softmmu/qemu-system-aarch64: No such file or directory

[epasveer]

So Qemu is a VM. You don't actually run gdbserver directly yourself? Qemu is running it. Correct? gdb is run directly by you via seergdb.

As Qemu is a VM, I wonder how/where it is getting the gdbserver program. I'm thinking it's not from your host machine? It may be old.

[epasveer]

../code/qemu/build/aarch64-softmmu/qemu-system-aarch64: No such file or directory

Got passed this error. I've installed qemu with arm support on my opensuse machine.

[epasveer]

So I watched this video. Maybe related to what you're doing.

https://www.youtube.com/watch?v=YoMs0RmWAQg

A couple more questions.

In the version of gdb that your Seergdb is configured with, what is the output of:

$ gdb
(gdb) set architecture  <RETURN>

The video uses add-symbol-file, just like you do. In fact, in the video, it is used more than once in a single debug session. So, to me, this appends debug information in gdb.

So I'm thinking the bli31.elf file is not the symbol file of your main program being debugged. But is one of few/many files that provided a subset of symbols. In the video, he loads them as he needs them. Is this the same for you?

Sorry for my misunderstanding here. I don't have much experience with embedded/VM debugging.

[epasveer]

In gdb's simplest case, debugging a program with an external symbol file is:

$ gdb
$ file myprogram
$ symbol-file myprogram.elf

myprogram.elf is the symbol file for myprogram. However, I'm thinking in cases like yours, you may have a subdirectory full of .elf files and they need to be handled differently (via add-symbol-file)

[hrw]

https://www.qemu.org/docs/master/system/gdb.html says that QEMU runs gdbstub.

Both host and VM are aarch64 architecture. I have only one version of gdbserver on my system.

QEMU starts, initialises gdbstub and waits for GDB connection. Then run SBSA_FLASH0.fd ROM. At beginning of it is TF-A component which consists of few elements named BL1, BL2, BL31. I want to debug BL31 part so load symbols for it.

"hbreak read_cpuinfo_from_dt" command allows me to run system until this function (in BL31) is started. Then I land in GDB and can debug what is going on.

I do not need other elf files so I am not loading them. Once I exit from 'read_cpuinfo_from_dt' function I either terminate process or let it run. In first case I usually change code, recompile/build image and restart QEMU. And reconnect Seer.

[epasveer]

I have a theory with this (because of gdbstubs). I'll need to make a change to the "connect" mode.

The current syntax is:

$ seergdb --connect <medium> [--sym <symbolfile>]

It think it should be this, where you can specify the executable name too.

$ seergdb --connect <medium> [--sym <symbolfile>] [executable] 

So your usage would be:

$ seergdb --connect localhost:1234 --sym /path/to/bl31.elf  /path/to/vmlunix

I'll get back to you.

[epasveer]

I've updated "main" with, hopefully, a fix. This should be the new syntax when starting. It allows you to specify the executable as well as the symbol file. The executable, I think, is "vmlinux" in your case? Also, you shouldn't need the "add-symbol-file" line.

$ seergdb --connect localhost:1234 --sym /path/to/bl31.elf  /path/to/vmlunix 

Try it out at your leisure. I'm interested in the contents of the the "Gdb Log" tab.

Thanks.

[hrw]

Launched QEMU as above and started Seer using ./seergdb --project tf-a.seer:

GDB output:

GNU gdb (Fedora Linux) 14.1-1.fc39
Copyright (C) 2023 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 \"aarch64-redhat-linux-gnu\".
Type \"show configuration\" for configuration details.
For bug reporting instructions, please see:
<https://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\".
warning: Remote gdbserver does not support determining executable automatically.RHEL <=6.8 and <=7.2 versions of gdbserver do not support such automatic executable detection.The following versions of gdbserver support it:- Upstream version of gdbserver (unsupported) 7.10 or later- Red Hat Developer Toolset (DTS) version of gdbserver from DTS 4.0 or later (only on x86_64)- RHEL-7.3 versions of gdbserver (on any architecture)

warning: No executable has been specified and target does not supportdetermining executable automatically.  Try using the \"file\" command.

warning: Remote gdbserver does not support determining executable automatically.RHEL <=6.8 and <=7.2 versions of gdbserver do not support such automatic executable detection.The following versions of gdbserver support it:- Upstream version of gdbserver (unsupported) 7.10 or later- Red Hat Developer Toolset (DTS) version of gdbserver from DTS 4.0 or later (only on x86_64)- RHEL-7.3 versions of gdbserver (on any architecture)

0x0000000000000000 in ?? ()

hbreak read_cpuinfo_from_dt
Hardware assisted breakpoint 1 at 0x3fcf5ae0: file plat/qemu/qemu_sbsa/sbsa_sip_svc.c, line 75.

Started session using 'Continue' button and ended in read_cpuinfo_from_dt file as expected:

[hrw]

And in my case there is no need to give executable as this part is handled by QEMU.

I debug firmware so it is far before Linux kernel gets loaded (if at all).