GDB symbols work for "break" and "print", but "list" fails with "No debugging symbols found"

2

There are tons of questions and answers about GDB and the "No debugging symbols found" warning, but all of those assume that the debugging symbols are not part of the .elf file.

I'm dealing with the following:

  • I have a .elf file with debugging symbols. I can verify this by doing objdump, and seeing a disassembly with the subroutine labels being present.
  • When I load the .elf file, it loads file correctly.
  • When I then do list to list the C code, I get No symbol table is loaded. Use the "file" command.
  • However, I can still do things like break main or p/x global_cntr!
  • When I do file progmem.elf, there's no difference in behavior: I get (No debugging symbols found in progmem.elf), but breakpoints etc still work.
  • GCC and GDB are using the same version of the GCC toolchain
  • I tried using -gdwarf-3 instead of -ggdb. No difference.

I'm lost...

I'm using a RISC-V toolchain, if that matters.

Here's an excerpt of my Makefile:


TARGET          = $(TOOLS_PREFIX)/riscv32-unknown-elf
AS              = $(TARGET)-as
ASFLAGS         = -march=$(MARCH) -mabi=ilp32
LD              = $(TARGET)-gcc
LDFLAGS         = -march=$(MARCH) -g -mabi=ilp32 -Wl,-Tsections.lds,-Map,progmem.map -ffreestanding -nostartfiles -Wl,--no-relax
CC              = $(TARGET)-gcc
CFLAGS          = -march=$(MARCH) -g -ggdb -mno-div -mabi=ilp32 -Wall -Wextra -pedantic -DCPU_FREQ=$(CPU_FREQ_MHZ)000000 $(CC_OPT)
...
progmem.elf: $(OBJ_FILES) top_defines.h sections.lds Makefile 
    $(LD) $(LDFLAGS) -o $@ $(OBJ_FILES) -lm 

And here's a log of my GDB session:

/opt/riscv32im/bin//riscv32-unknown-elf-gdb progmem.elf \
    -ex "target remote localhost:3333"
...
Remote debugging using localhost:3333
0x0000002e in rdcycle64 ()
(gdb) 
(gdb) 
(gdb) monitor soft_reset_halt
requesting target halt and executing a soft reset
(gdb) file progmem.elf
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading symbols from progmem.elf...
(No debugging symbols found in progmem.elf)
(gdb) br main
Breakpoint 1 at 0x5d6
(gdb) load
Loading section .memory, size 0x5790 lma 0x0
Start address 0x0, load size 22416
Transfer rate: 23 KB/sec, 11208 bytes/write.
(gdb) c
Continuing.

Program stopped.
0x000005d6 in main ()
(gdb) p/x global_cntr
$1 = 0x0
(gdb) l
No symbol table is loaded.  Use the "file" command.
(gdb) 
debugging
gdb
symbols
asked on Stack Overflow Mar 9, 2021 by Tom Verbeure

2 Answers

1

I have a .elf file with debugging symbols. I can verify this by doing objdump, and seeing a disassembly with the subroutine labels being present.

Debugging symbols are not the same as symbols. For disassembly, you only need the latter. For source listing you need the former.

I can still do things like break main or p/x global_cntr!

These also require only the symbol table.

You can confirm that you don't have debug symbols using objdump -g progmem.elf or readelf -wi progmem.elf.

Your command lines look like debug symbols should be included, but there is no telling what you do with .debug_* sections in your sections.lds linker script. Probably you discard them, which would explain why they aren't there.

Update:

Do you by any chance has an example sections.lds file that has them included?

ld --verbose should print the default linker script. Here is one example.

answered on Stack Overflow Mar 10, 2021 by Employed Russian • edited Mar 10, 2021 by Employed Russian
1

My original linker script was the following:

SECTIONS {
    .memory : {
        . = 0x00000;
        start*(.text);
        *(.text);
        *(*);
        end = .;
    }
}

I suspect that my issue was caused by the catchall *(*); which moved all sections into the .text section.

I replaced it with the following script:


MEMORY
{
    ram (ax)  : ORIGIN = 0x00000000, LENGTH = 16K
}

SECTIONS {
}

After this, .debug_* symbols are included.

This script should be refined with more precise placement of various sections, but it's good enough to unblock me.

answered on Stack Overflow Mar 10, 2021 by Tom Verbeure • edited Mar 10, 2021 by Tom Verbeure

User contributions licensed under CC BY-SA 3.0