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:
load
the .elf file, it loads file correctly.list
to list the C code, I get No symbol table is loaded. Use the "file" command.
break main
or p/x global_cntr
!file progmem.elf
, there's no difference in behavior: I get (No debugging symbols found in progmem.elf)
, but breakpoints etc still work.-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)
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.
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.
User contributions licensed under CC BY-SA 3.0