4 To run the gdb server, do (you do not need sudo if you have set up
5 permissions correctly):
6 $ make -C build && sudo ./build/st-util 1234 /dev/sg1
9 (gdb) target remote :1234
13 Resetting the chip from GDB
14 ===========================
16 You may reset the chip using GDB if you want. You'll need to use `target
17 extended-remote' command like in this session:
18 (gdb) target extended-remote localhost:1111
19 Remote debugging using localhost:1111
20 0x080007a8 in _startup ()
22 Kill the program being debugged? (y or n) y
24 Starting program: /home/whitequark/ST/apps/bally/firmware.elf
26 Remember that you can shorten the commands. `tar ext :1111' is good enough
29 Running programs from SRAM
30 ==========================
32 You can run your firmware directly from SRAM if you want to. Just link
33 it at 0x20000000 and do
34 (gdb) load firmware.elf
36 It will be loaded, and pc will be adjusted to point to start of the
37 code, if it is linked correctly (i.e. ELF has correct entry point).
42 The GDB stub ships with a correct memory map, including the flash area.
43 If you would link your executable to 0x08000000 and then do
44 (gdb) load firmware.elf
45 then it would be written to the memory.
50 Q: My breakpoints do not work at all or only work once.
52 A: Optimizations can cause severe instruction reordering. For example,
53 if you are doing something like `REG = 0x100;' in a loop, the code may
54 be split into two parts: loading 0x100 into some intermediate register
55 and moving that value to REG. When you set up a breakpoint, GDB will
56 hook to the first instruction, which may be called only once if there are
57 enough unused registers. In my experience, -O3 causes that frequently.
59 Q: At some point I use GDB command `next', and it hangs.
61 A: Sometimes when you will try to use GDB `next' command to skip a loop,
62 it will use a rather inefficient single-stepping way of doing that.
63 Set up a breakpoint manually in that case and do `continue'.