Hello Everybody,
I am new to coreboot build environment and need your help in using gdb with coreboot.
I want to use gdb to take a closer look at the stages in coreboot and the order they are executed in. I also want to single step through the code to see what functions are being called in each stage and during transition from one stage to another. Firstly, I am not even sure if gdb works during transition. Does it?
These are the steps I followed:
1. First I set up the coreboot environment by following this tutorial. https://doc.coreboot.org/tutorial/part1.html. (I also enabled Gdb Wait by going to Debugging menu in coreboot's configuration.)
2. Then I ran the image on qemu $ qemu-system-x86_64 -bios build/coreboot.rom -serial stdio -s -S
3. In another terminal, I started gdb and entered the following command $ target remote localhost:1234
4. From here, I am able to single step using 'si' but I am not able to set a breakpoint using 'break' at say romstage.c or hardwaremain.c. I get the following error: ''No symbol table is loaded. Use the "file" command. Make breakpoint pending on future shared library load? (y or [n])''
Can anyone tell me where I went wrong?
Thanks,
Harshit
You need to compile with debug symbols if you want to break using line numbers of a file. Else you have to set breakpoints on address
sin9yt
Hi Sindhoor,
Thanks for your reply. I added the debug symbols using the following command $ add-symbol-file build/cbfs/fallback/ramstage.debug 0x0
Now I am able to set a breakpoint at a particular line number. But when I enter 'continue', it just never reaches that breakpoint. (I tried with both Gdb Wait enabled and disabled)
What could be wrong?
-Harshit
Harshit Sharma wrote:
Hi Sindhoor,
Thanks for your reply. I added the debug symbols using the following command $ add-symbol-file build/cbfs/fallback/ramstage.debug 0x0
Now I am able to set a breakpoint at a particular line number. But when I enter 'continue', it just never reaches that breakpoint. (I tried with both Gdb Wait enabled and disabled)
What could be wrong?
-Harshit
It could be possible a new child process might have been forked. If that's the case set gdb to follow child process.
In any case, I'd advise you to break on the address instead of line numbers.