Giter VIP home page Giter VIP logo

esp-gdbstub's Introduction

GDBSTUB

Intro

While the ESP8266 supports the standard Gnu set of C programming utilities, for now the choice of debuggers has been limited: there is an attempt at OpenOCD support, but at the time of writing, it doesn't support hardware watchpoints and breakpoints yet, and it needs a separate JTAG adapter connecting to the ESP8266s JTAG pins. As an alternative, Cesanta has implemented a barebonesGDB stub in their Smart.js solution - unfortunately, this only supports exception catching and needs some work before you can use it outside of the Smart.js platform. Moreover, it also does not work with FreeRTOS.

For internal use, we at Espressif desired a GDB stub that works with FreeRTOS and is a bit more capable, so we designed our own implementation of it. This stub works both under FreeRTOS as well as the OS-less SDK and is able to catch exceptions and do backtraces on them, read and write memory, forward [os_]printf statements to gdb, single-step instructions and set hardware break- and watchpoints. It connects to the host machine (which runs gdb) using the standard serial connection that's also used for programming.

In order to be useful the gdbstub has to be used in conjunction with an xtensa-lx106-elf-gdb, for example as generated by the esp-open-sdk project.

Usage

  • Grab the gdbstub project and put the files in a directory called 'gdbstub' in your project. You can do this either by checking out the Git repo, or adding the Git repo as a submodule to your project if it's already in Git.
  • Modify your Makefile. You'll need to include the gdbstub sources: if your Makefile is structured like the ones in the Espressif examples, you can add gdbstub to the SUBDIRS define and gdbstub/libgdbstub.a to the COMPONENTS_eagle.app.v6 define. Also, you probably want to add -ggdb to your compiler flags (TARGET_LDFLAGS) and, if you are debugging, change any optimation flags (-Os, -O2 etc) into -Og. Finally, make sure your Makefile also compiles .S files.
  • Configure gdbstub by editting gdbstub-cfg.h. There are a bunch of options you can tweak: FreeRTOS or bare SDK, private exception/breakpoint stack, console redirection to GDB, wait till debugger attachment etc. You can also configure the options by including the proper -Dwhatever gcc flags in your Makefiles.
  • In your user_main.c, add an #include <../gdbstub/gdbstub.h> and call gdbstub_init(); somewhere in user_main.
  • Compile and flash your board.
  • Run gdb, depending on your configuration immediately after resetting the board or after it has run into an exception. The easiest way to do it is to use the provided script: xtensa-lx106-elf-gdb -x gdbcmds -b 38400 Change the '38400' into the baud rate your code uses. You may need to change the gdbcmds script to fit the configuration of your hardware and build environment.

Notes

  • Using software breakpoints ('br') only works on code that's in RAM. Code in flash can only have a hardware breakpoint ('hbr').
  • Due to hardware limitations, only one hardware breakpount and one hardware watchpoint are available.
  • Pressing control-C to interrupt the running program depends on gdbstub hooking the UART interrupt. If some code re-hooks this afterwards, gdbstub won't be able to receive characters. If gdbstub handles the interrupt, the user code will not receive any characters.
  • Continuing from an exception is not (yet) supported in FreeRTOS mode.
  • The WiFi hardware is designed to be serviced by software periodically. It has some buffers so it will behave OK when some data comes in while the processor is busy, but these buffers are not infinite. If the WiFi hardware receives lots of data while the debugger has stopped the CPU, it is bound to crash. This will happen mostly when working with UDP and/or ICMP; TCP-connections in general will not send much more data when the other side doesn't send any ACKs.

License

This gdbstub is licensed under the Espressif MIT license, as described in the License file.

Thanks

  • Cesanta, for their initial ESP8266 exception handling only gdbstub,
  • jcmvbkbc, for providing an incompatible but interesting gdbstub for other Xtensa CPUs,
  • Sysprogs (makers of VisualGDB), for their suggestions and bugreports.

esp-gdbstub's People

Contributors

everslick avatar igrr avatar spritetm avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

esp-gdbstub's Issues

warnings from gdbstub.c

compiling gdbstub.c gives these warnings:

/build/src/maincpu/../gdbstub/gdbstub.c: In function 'gdbstub_handle_debug_exception':
/build/src/maincpu/../gdbstub/gdbstub.c:568:2: warning: implicit declaration of function 'ets_wdt_disable'; did you mean 'wifi_wps_disable'? [-Wimplicit-function-declaration]
  ets_wdt_disable();
  ^~~~~~~~~~~~~~~
  wifi_wps_disable
/build/src/maincpu/../gdbstub/gdbstub.c:601:2: warning: implicit declaration of function 'ets_wdt_enable'; did you mean 'wifi_wps_enable'? [-Wimplicit-function-declaration]
  ets_wdt_enable();
  ^~~~~~~~~~~~~~
  wifi_wps_enable
/build/src/maincpu/../gdbstub/gdbstub.c: In function 'install_uart_hdlr':
/build/src/maincpu/../gdbstub/gdbstub.c:717:32: warning: passing argument 2 of 'ets_isr_attach' from incompatible pointer type [-Wincompatible-pointer-types]
  ets_isr_attach(ETS_UART_INUM, uart_hdlr, NULL);
                                ^~~~~~~~~
In file included from /build/src/maincpu/../gdbstub/gdbstub.c:11:
/home/me/sdk/include/ets_sys.h:67:38: note: expected 'ets_isr_t' {aka 'void (*)(void *)'} but argument is of type 'void (*)(void *, void *)'
 void ets_isr_attach(int i, ets_isr_t func, void *arg);
                            ~~~~~~~~~~^~~~

Using GDB for online debugging ESP8266

Hi,

For a couple of days, I've been struggling to configure debugging for ESP8266 running on Arduino and using PlatformIO.
I managed to build a proper binary file with http://blog.squix.org/2016/04/esp8266-offline-debugging-with.html:

  1. Added build_flags = -Og -ggdb -DDEBUG_ESP_PORT=Serial to platformio.ini
    2.Downloaded full xtensa SDK as this provided for PIO does not include xtensa GDB
    Thanks to these steps I am able to offline debug - see lines numbers etc,but I cannot make it work with online debugging. Here is what I've done:
  2. Added GDBStub.h include to my main class
  3. Started GDB with firmware that has debugging symbols included(from step 1) to debug via COM - set ,baud rate to 115200 (the same as I use for normal state check via serial monitor - wifi messages etc.) .
  4. I get no response - only timeouts etc
  5. In the result, I would like to use CLion to insert breakpoints watches etc.

Can someone pint me what I'm missing ? I have 2 suspicions :

  • Is including only GDBAtub.h enough or should I call gdb_init somewhere (its's not recognized as a function) or do anything more.
  • Baud rate - should I use the same as the one set for serial communication messages (115200) ?

I am using Windows.

unable to build with NONEOS sdk

trying to build my project with gdbstub and NONEOS sdk 3.0.5 gives these linker errors:

/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: /build/src/maincpu/build/liblibmaincpu.a(gdbstub.c.o): in function `gdbPacketHex':
gdbstub.c:(.irom0.text+0x1c1): dangerous relocation: call0: call target out of range: memcpy
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: /build/src/maincpu/build/liblibmaincpu.a(gdbstub.c.o): in function `sendReason':
gdbstub.c:(.irom0.text+0x4fe): dangerous relocation: call0: call target out of range: memcpy
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: /build/src/maincpu/build/liblibmaincpu.a(gdbstub.c.o): in function `gdbHandleCommand':
gdbstub.c:(.irom0.text+0x829): dangerous relocation: call0: call target out of range: strncmp
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: gdbstub.c:(.irom0.text+0x849): dangerous relocation: call0: call target out of range: strncmp
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: gdbstub.c:(.irom0.text+0x879): dangerous relocation: call0: call target out of range: gdbstub_icount_ena_single_step
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: gdbstub.c:(.irom0.text+0x895): dangerous relocation: call0: call target out of range: strncmp
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: gdbstub.c:(.irom0.text+0x8f5): dangerous relocation: call0: misaligned call target: gdbstub_set_hw_breakpoint
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: gdbstub.c:(.irom0.text+0x9b7): dangerous relocation: call0: call target out of range: gdbstub_set_hw_watchpoint
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: gdbstub.c:(.irom0.text+0xa11): dangerous relocation: call0: call target out of range: gdbstub_del_hw_breakpoint
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: gdbstub.c:(.irom0.text+0xa4f): dangerous relocation: call0: misaligned call target: gdbstub_del_hw_watchpoint
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: /build/src/maincpu/build/liblibmaincpu.a(gdbstub.c.o): in function `setaregval':
gdbstub.c:(.irom0.text+0xbd9): dangerous relocation: call0: call target out of range: os_printf_plus
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: /build/src/maincpu/build/liblibmaincpu.a(gdbstub.c.o): in function `emulLdSt':
gdbstub.c:(.irom0.text+0xd79): dangerous relocation: call0: call target out of range: os_printf_plus
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: /build/src/maincpu/build/liblibmaincpu.a(gdbstub.c.o): in function `gdbstub_handle_debug_exception':
gdbstub.c:(.irom0.text+0xd99): dangerous relocation: call0: call target out of range: ets_wdt_disable
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: gdbstub.c:(.irom0.text+0xe7d): dangerous relocation: call0: call target out of range: ets_wdt_enable
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: /build/src/maincpu/build/liblibmaincpu.a(gdbstub.c.o): in function `gdb_exception_handler':
gdbstub.c:(.irom0.text+0xe9d): dangerous relocation: call0: call target out of range: gdbstub_save_extra_sfrs_for_exception
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: gdbstub.c:(.irom0.text+0xea7): dangerous relocation: call0: call target out of range: ets_memcpy
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: gdbstub.c:(.irom0.text+0xec7): dangerous relocation: call0: call target out of range: ets_wdt_disable
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: gdbstub.c:(.irom0.text+0xeda): dangerous relocation: call0: call target out of range: ets_wdt_enable
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: gdbstub.c:(.irom0.text+0xee6): dangerous relocation: call0: call target out of range: ets_memcpy
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: /build/src/maincpu/build/liblibmaincpu.a(gdbstub.c.o): in function `install_exceptions':
gdbstub.c:(.irom0.text+0xf86): dangerous relocation: call0: call target out of range: memcpy
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: gdbstub.c:(.irom0.text+0xf9e): dangerous relocation: call0: call target out of range: _xtos_set_exception_handler
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: /build/src/maincpu/build/liblibmaincpu.a(gdbstub.c.o): in function `uart_hdlr':
gdbstub.c:(.irom0.text+0xfd5): dangerous relocation: call0: call target out of range: gdbstub_save_extra_sfrs_for_exception
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: gdbstub.c:(.irom0.text+0x101b): dangerous relocation: call0: call target out of range: ets_memcpy
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: gdbstub.c:(.irom0.text+0x1032): dangerous relocation: call0: call target out of range: ets_wdt_disable
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: gdbstub.c:(.irom0.text+0x1045): dangerous relocation: call0: call target out of range: ets_wdt_enable
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: gdbstub.c:(.irom0.text+0x1051): dangerous relocation: call0: call target out of range: ets_memcpy
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: /build/src/maincpu/build/liblibmaincpu.a(gdbstub.c.o): in function `install_uart_hdlr':
gdbstub.c:(.irom0.text+0x1076): dangerous relocation: call0: call target out of range: ets_isr_attach
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: gdbstub.c:(.irom0.text+0x1091): dangerous relocation: call0: call target out of range: ets_isr_unmask
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: /build/src/maincpu/build/liblibmaincpu.a(gdbstub.c.o): in function `gdbstub_init':
gdbstub.c:(.irom0.text+0x10b2): dangerous relocation: call0: call target out of range: ets_install_putc1
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: gdbstub.c:(.irom0.text+0x10bb): dangerous relocation: call0: call target out of range: gdbstub_init_debug_entry
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: gdbstub.c:(.irom0.text+0x10be): dangerous relocation: call0: call target out of range: gdbstub_do_break
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: /build/src/maincpu/build/liblibmaincpu.a(gdbstub-entry.S.o):(.literal+0x8): undefined reference to `gdbstub_handle_uart_int'
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: /build/src/maincpu/build/liblibmaincpu.a(gdbstub-entry.S.o): in function `noIcountReset':
(.text+0x6d): dangerous relocation: call0: call target out of range: gdbstub_handle_debug_exception
/home/me/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/8.4.0/../../../../xtensa-lx106-elf/bin/ld: /build/src/maincpu/build/liblibmaincpu.a(gdbstub-entry.S.o): in function `gdbstub_user_exception_entry':
(.text+0x129): undefined reference to `gdbstub_handle_user_exception'
collect2: error: ld returned 1 exit status

Question

i'm moving all of my library examples to the examples folder in the IDE, do i need to put the entry.S in with the ESP8266 sketch?

XCHAL_DEBUGLEVEL

It couldn't find XCHAL_DEBUGLEVEL in my constelation with the standard IoT SDK.

Reduce gdbstub ROM usage

Hello,

I've been using the gdb stub for a while, but now I'm really working on the limit of the firmware size for the latest RTOS SDK, it's getting impossible to compile the firmware including the gdbstub with the debugger flags.I'm still able to compile the firmware using the Os flag without debugger flags. My firmware has about 370kb.
I really would like to keep using the gdbstub, it is really great and useful. Do you have any other ideas to reduce the gdbstub rom size or at least try to optimize it?

Adding the external libminic to compiler flags, will reduce the firmware size in about 15kb.

Thanks
Regards

esp32 compatible?

Hello,

I wanted to know if this gdb stub could do any good with the esp32?

thanks in advance

Unable to debug step by step.

I am trying to incorporate esp-gdbstub into Sming (https://github.com/slaff/Sming/tree/feature/gdb-dev), an esp C++ framework. And I have some difficulties debugging step by step. It would be great if someone can tell me what am I doing wrong.

So I compiled the sample program ( https://github.com/slaff/Sming/blob/feature/gdb-dev/Basic_Debug/app/application.cpp ) that turns the led on and off. I flashed it on the device and restart the devices. Then started gdb with the following options

xt-gdb -b 115200

When gdb started I ran the following commands

(gdb) file out/build/app.out 
(trace) gdbarch_init()
Load new symbol table from "/media/slavey/416431e8-fd46-4982-896d-5025a72dd361/slavey/dev/esp8266.dev.box/dev/Sming/Basic_Debug/out/build/app.out"? (y or n) y
(trace) gdbarch_init()
Reading symbols from /media/slavey/416431e8-fd46-4982-896d-5025a72dd361/slavey/dev/esp8266.dev.box/dev/Sming/Basic_Debug/out/build/app.out...done.
(gdb) set remotedebug 1
No symbol "remotedebug" in current context.
(gdb) set remotelogfile gdb_rsp_logfile.txt
(gdb) set serial baud 115200
Undefined set serial command: "baud 115200".  Try "help set serial".
(gdb) set remotebaud 115200
(gdb) set remote hardware-breakpoint-limit 1
(gdb) set remote hardware-watchpoint-limit 1
(gdb) set debug xtensa 4
(gdb) target remote /dev/ttyUSB0
Remote debugging using /dev/ttyUSB0
(trace) xtensa_unwind_pc (next_frame = 0x97f2120)
(info ) [xtensa_unwind_pc] pc = 0x40237c27
gdbstub_do_break_breakpoint_addr () at /home/slavey/dev/esp8266.dev.box/dev/Sming/Sming//gdbstub/gdbstub-entry.S:399
399     break 0,0

(gdb) break init
(trace) xtensa_alloc_frame_cache ()
(trace) call0_analyze_prologue (start = 0x40237c27, pc = 0x40237c27, ...)
(verb ) [call0_analyze_prologue] stopped at instr addr 0x40237c27, succeeded
(trace) xtensa_skip_prologue (start_pc = 0x40105678)
(trace) xtensa_skip_prologue (start_pc = 0x40105678)
(trace) xtensa_breakpoint_from_pc (pc = 0x40105678)
Breakpoint 1 at 0x40105678: file app/application.cpp, line 22.

(gdb) l
394     addi    a1, a1, -16
395     s32i    a15, a1, 12
396     mov     a15, a1
397 
398 gdbstub_do_break_breakpoint_addr:
399     break 0,0
400 
401     mov     a1, a15
402     l32i    a15, a1, 12
403     addi    a1, a1, 16
(gdb) run
The "remote" target does not support "run".  Try "help target" or "continue".

Up to here everything seems to be work as expected. The LED on the device is not blinking and I can start the program.

(gdb) continue
Continuing.
(trace) xtensa_breakpoint_from_pc (pc = 0x40105678)
(trace) xtensa_breakpoint_from_pc (pc = 0x40105678)
(trace) xtensa_unwind_pc (next_frame = 0x97f2120)
(info ) [xtensa_unwind_pc] pc = 0x40105678

The debugger stops at the first breakpoint, which is great.

Breakpoint 1, init () at app/application.cpp:22
22  {

I can also see information about variables

(gdb) print state
$1 = true

But then I am not able to debug the application step by step. On the first execution of "next" I get back some result but all following next commands give me errors Cannot find bounds of current function.

Below is an output with more results.

(gdb) next
(trace) xtensa_alloc_frame_cache ()
(trace) call0_analyze_prologue (start = 0x40105678, pc = 0x40105678, ...)
(verb ) [call0_analyze_prologue] stopped at instr addr 0x40105678, succeeded
(trace) xtensa_unwind_pc (next_frame = 0x97f2120)
(info ) [xtensa_unwind_pc] pc = 0x40000504
(trace) xtensa_alloc_frame_cache ()
(trace) xtensa_unwind_pc (next_frame = 0x97f2180)
(info ) [xtensa_unwind_pc] pc = 0x40235cef
(trace) xtensa_alloc_frame_cache ()
(trace) call0_analyze_prologue (start = 0x40235cc8, pc = 0x40235cef, ...)
(verb ) [call0_analyze_prologue] instr addr = 0x40235cc8, opc = 16
(trace) call0_classify_opcode (..., opc = 16)
(verb ) [call0_analyze_prologue] instr addr = 0x40235ccb, opc = 74
(trace) call0_classify_opcode (..., opc = 74)
(verb ) [call0_analyze_prologue] instr addr = 0x40235cce, opc = 53
(trace) call0_classify_opcode (..., opc = 53)
(verb ) [call0_analyze_prologue] stopped at instr addr 0x40235cce, succeeded
0x40000504 in ?? ()
(gdb) next
Cannot find bounds of current function

Can it be that I am typing the next command too slow ( I don't think it takes me more than a second to press enter ) ? Or is the location of the function not correct ? I have instructions saying that the init function should be in .iram.text section. Is that the right place?

Any ideas why "next" is not working or what am I doing wrong?

P.S: If I remove the breakpoint and run continue then the LED starts to blink and I can see the usual output:

(gdb) delete 1
(gdb) continue
Continuing.
(trace) xtensa_alloc_frame_cache ()
(trace) call0_analyze_prologue (start = 0x40105678, pc = 0x40105678, ...)
(verb ) [call0_analyze_prologue] stopped at instr addr 0x40105678, succeeded
mode : softAP(1a:fe:34:f3:74:e7)
add if1
dhcp server start:(ip:192.168.4.1,mask:255.255.255.0,gw:192.168.4.1)
bcn 100

Disarming timer in debug mode does not work

I have a timer defined as

os_timer_t timer;

I am starting the timer to execute periodic checks with the following command

ets_timer_setfn(&timer, (os_timer_func_t *)processing, this);   
ets_timer_arm_new(&timer, 30000, 0, 0); 

At some point the timer is triggered and the processing function is called. Which is fine.

Then later on in the code I am trying to disable the timer using this command

ets_timer_disarm(&timer);

And the function is executed.

Unfortunately it seems that the timer is not disabled when I compile the application in debug mode (with GDBStub) and the processing function is called over and over again. The application works as expected in non-debug mode.

Any ideas what am I doing wrong?

GDB performs step instead of next

There is a code like this:
8: void user_init()
9: {
10: f2();
11: }

both are located in flash.

Scenario:

  1. hbr user_init
  2. c
    It stops at the beginnign of user_init, line 9
  3. next
    It shows
    10 f2()
  4. next
    Expectation is that it goes to line 11
    Actual result is that it goes into f2 and produces the message like this:
    Warning:
    Cannot insert breakpoint 0.
    Error accessing memory address 0x4028f3ab: Input/output error.

Can not Debugging esp8266 using esp-gdbstub

Hello,

I tried implementing gdbstub with many reference(as given below) but don't get any success.
http://kacangbawang.com/esp8266-sdk-how-to-debug-with-gdb/#comment-20341
http://correderajorge.github.io/esp-gdb-freertos/
https://blog.attachix.com/live-debugging-with-open-source-tools-programming-for-esp8266-part-4/

But at the end of every implementation when I hit "target remote /dev/ttyUSB0" , its shows nothing .
And when i am trying to put breakpoints before setting remote target gdb crash with "segmentation fault core dump".

Can anyone help me to solve it?

Bug with breakpoint

Breakpoints are not working. Hitting a breakpoint generates an instruction fetch error. Step or Next is working.

Environment:
gdbstub integrated in RTOS SDK (tag v2.0.0-branch, commit 936c92a).
hardware: board found on aliexpress, similar to nodemcu

Investigation:
I found out that when break is executed, the pc jumps normally to _DebugExceptionVector. Here registers a2 and excsave2 are exchanged. Then there is a jump to a2. Unfortunately and I don't know why the content of excsave2 which is supposed to contain the address gdbstub_debug_exception_entry, does content something else. So it jumps at a non valid address which in the end generates an instruction fetch error.
Doing step by step does not modify the content of excsave2, only typing 'c' in gdb modify it. I don't know why.
I fixed the issue by hardcoding the jump to gdbstub_debug_exception_entry instead of using content of a2 register for this jump. Problem is now solved.

Unable to compile the code with SDK 2.1.0

In SDK 2.1.0 and newer the definition of ets_isr_attach changed to

void ets_isr_attach(int i, ets_isr_t func, void *arg);

Therefore the compilation ends up with an error like this:

CC third-party/esp-gdbstub/gdbstub.c
third-party/esp-gdbstub/gdbstub.c: In function 'install_uart_hdlr':
third-party/esp-gdbstub/gdbstub.c:722:2: error: passing argument 2 of 'ets_isr_attach' from incompatible pointer type [-Werror]
  ets_isr_attach(ETS_UART_INUM, uart_hdlr, NULL);
  ^
In file included from system/include/esp_systemapi.h:6:0,
                 from include/user_config.h:27,
                 from third-party/esp-gdbstub/gdbstub.c:11:
/home/slavey/dev/esp8266.dev.box/Espressif/sdk//include/ets_sys.h:67:6: note: expected 'ets_isr_t' but argument is of type 'void (*)(void *, void *)'
 void ets_isr_attach(int i, ets_isr_t func, void *arg);
      ^
cc1: all warnings being treated as errors

So my question is can it be that the SDK definition of ets_isr_t is wrong or is there a way to fix the Gdbstub code so that it uses the current definition and still gets the frame as second parameter in the callback?

Correct makefile to compile .S files

Hello,

I'm trying to include the gdbstub on my project, but I'm having problems modifying the makefile to compile .S files. When I changed the makefile to compile .S files, it results in erros on the OBJDUMP and then it has also corrupted the app.a file used to generated the firmware.

UPDATE: I've figured out how to correctly update the makefile to compile .S files.
This is an example of working makefile:

AS 		:= $(XTENSA_TOOLS_ROOT)/xtensa-lx106-elf-as
CC		:= $(XTENSA_TOOLS_ROOT)/xtensa-lx106-elf-gcc
CXX		:= $(XTENSA_TOOLS_ROOT)/xtensa-lx106-elf-g++
AR		:= $(XTENSA_TOOLS_ROOT)/xtensa-lx106-elf-ar
LD		:= $(XTENSA_TOOLS_ROOT)/xtensa-lx106-elf-gcc
NM              := $(XTENSA_TOOLS_ROOT)/xtensa-lx106-elf-nm
OBJCOPY		:= $(XTENSA_TOOLS_ROOT)/xtensa-lx106-elf-objcopy
OBJDUMP		:= $(XTENSA_TOOLS_ROOT)/xtensa-lx106-elf-objdump

SRC_DIR		:= $(MODULES)
BUILD_DIR	:= $(addprefix $(BUILD_BASE)/,$(MODULES))

SDK_LIBDIR	:= $(addprefix $(SDK_BASE)/,$(SDK_LIBDIR))
SDK_INCDIR	:= $(addprefix -I$(SDK_BASE)/,$(SDK_INCDIR))

AS_SRC		:= $(foreach sdir,$(SRC_DIR),$(wildcard $(sdir)/*.S)) 
C_SRC		:= $(foreach sdir,$(SRC_DIR),$(wildcard $(sdir)/*.c)) 
CXX_SRC		:= $(foreach sdir,$(SRC_DIR),$(wildcard $(sdir)/*.cpp))
AS_OBJ		:= $(patsubst %.S,%.o,$(AS_SRC))
C_OBJ		:= $(patsubst %.c,%.o,$(C_SRC))
CXX_OBJ		:= $(patsubst %.cpp,%.o,$(C_OBJ))
OBJ		:= $(patsubst %.o,$(BUILD_BASE)/%.o,$(AS_OBJ) $(C_OBJ))
LIBS		:= $(addprefix -l,$(LIBS))
APP_AR		:= $(addprefix $(BUILD_BASE)/,$(TARGET)_app.a)
TARGET_OUT	:= $(addprefix $(BUILD_BASE)/,$(TARGET).out)

LD_SCRIPT	:= $(addprefix -T$(SDK_BASE)/$(SDK_LDDIR)/,$(LD_SCRIPT))

INCDIR		:= $(addprefix -I,$(SRC_DIR))
EXTRA_INCDIR	:= $(addprefix -I,$(EXTRA_INCDIR))
MODULE_INCDIR	:= $(addsuffix /include,$(INCDIR))

V ?= $(VERBOSE)
ifeq ("$(V)","1")
Q :=
vecho := @true
else
Q := @
vecho := @echo
endif

vpath %.S $(SRC_DIR)
vpath %.c $(SRC_DIR)
vpath %.cpp $(SRC_DIR)

define compile-objects
$1/%.o: %.S
	$(vecho) "ASM $$<"
	$(Q) $(CC) $(INCDIR) $(MODULE_INCDIR) $(EXTRA_INCDIR) $(SDK_INCDIR) $(CFLAGS) -D__ASSEMBLER__ -c $$< -o $$@
$1/%.o: %.c
	$(vecho) "CC $$<"
	$(Q) $(CC) $(INCDIR) $(MODULE_INCDIR) $(EXTRA_INCDIR) $(SDK_INCDIR) $(CFLAGS) -c $$< -o $$@
$1/%.o: %.cpp
	$(vecho) "C++ $$<"
	$(Q) $(CXX) $(INCDIR) $(MODULE_INCDIR) $(EXTRA_INCDIR) $(SDK_INCDIR) $(CXXFLAGS) -c $$< -o $$@
endef

$(APP_AR): $(OBJ)
	$(vecho) "AR $@ $^"
	$(Q) $(AR) ru $@ $^

gdbstub linking will not fit in iram1_0_seg

I have downloaded the esp-gdbstub repository, compiled the sources and placed them in an archive. When I now try and link the gdbstub archive with me simple C application, I find that I get the error:

a.out section '.text' will not fit in region 'iram1_0_seg'

Running objdump -h over the archive produces the following:

gdbstub.o:     file format elf32-xtensa-le

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .literal      00000000  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .irom0.literal 00000000  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .text         00001133  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  3 .data         00000008  00000000  00000000  00001168  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  4 .bss          00000128  00000000  00000000  00001170  2**2
                  ALLOC
  5 .rodata       000000aa  00000000  00000000  00001170  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .irom0.text   000000c2  00000000  00000000  0000121c  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  7 .comment      00000022  00000000  00000000  000012de  2**0
                  CONTENTS, READONLY
  8 .xtensa.info  00000038  00000000  00000000  00001300  2**0
                  CONTENTS, READONLY
  9 .xt.lit       000000b8  00000000  00000000  00001338  2**0
                  CONTENTS, RELOC, READONLY
 10 .xt.prop      00000be8  00000000  00000000  000013f0  2**0
                  CONTENTS, RELOC, READONLY

gdbstub-entry.o:     file format elf32-xtensa-le

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .literal      00000000  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .text         0000023f  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  2 .data         00000000  00000000  00000000  00000273  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          00000000  00000000  00000000  00000273  2**0
                  ALLOC
  4 .xtensa.info  00000038  00000000  00000000  00000273  2**0
                  CONTENTS, READONLY
  5 .xt.lit       00000008  00000000  00000000  000002ab  2**0
                  CONTENTS, RELOC, READONLY
  6 .xt.prop      00000144  00000000  00000000  000002b3  2**0
                  CONTENTS, RELOC, READONLY

Has anyone run up against this puzzle before?

Also posted to the forum here:

http://bbs.espressif.com/viewtopic.php?f=7&t=1424

Bigger ROM images with GDBStub cause the device to reset itself constantly

I am experiencing some strange issues with Esp-GDBStub. If the size of the application grows above some size and ESP-GDBStub is compiled in it then the device start to reset itself very early in the booting. The same application without GDBStub is working as expected. Can it be that the application is overwriting some areas of the memory that GDBStub uses or vise-versa? The resets are happening with both the NONOS and RTOS SDKs. If needed I can provide source code, out files, dump (xtensa-lx106-elf-objdump -x -s) from the app with and without GDBStub compiled in it.

Can't step over the vTaskDelay

There is a code like this:

    SET_PERI_REG_BITS(UART_CLKDIV(0), UART_CLKDIV_CNT, UART_CLK_FREQ / 115200, UART_CLKDIV_S);
    gdbstub_init();
    vTaskDelay(1000/ portTICK_RATE_MS);
    test();

When gdb started, I ran the 'next' commands to vTaskDelay,
gdb reports: "Single stepping until exit from function vTaskDelay,which has no line number information.", and step into 'vTaskDelay'
It seems gdb ran step instead of next.

I knew this situation like https://github.com/espressif/esp-gdbstub/issues/5
but I didn't add hardware break.

Here is gdb log:

GNU gdb (crosstool-NG crosstool-ng-1.22.0-60-g37b07f6f) 7.10
...
Type "apropos word" to search for commands related to "word".
gdbstub_do_break_breakpoint_addr () at gdbstub-entry.S:399
399		break 0,0
(gdb) next
warning: 
Unrecognised function prologue. Stack trace cannot be resolved. This message will not be repeated in this session.

gdbstub_do_break_breakpoint_addr () at gdbstub-entry.S:402
402		l32i	a15, a1, 12
(gdb) next
403		addi	a1, a1, 16
(gdb) next
404		ret
(gdb) next
gdbstub_init () at gdbstub.c:790
790	}
(gdb) next
user_init () at user_main.c:119
119	    vTaskDelay(1000/ portTICK_RATE_MS);
(gdb) next
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x4023d7f4

0x40236110 in vTaskDelay ()
(gdb) next
Single stepping until exit from function vTaskDelay,
which has no line number information.
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x4023612c

0x40235ef8 in vTaskSuspendAll ()
(gdb)

My code is base on ESP8266_RTOS_SDK/examples/project_template/,
and xtensa-lx106-elf is from esp-open-sdk

Unable to insert Breakpoints on ESP8266 Debugging

Hello to everyone. I'm having trouble when degugging the module, with the example code Blinky. The debugging session is started correctly, but when trying to insert a breakpoint, i get a warning saying: "Breakpoint Installation Failed". Apart from that, I can't debug step by step, the button isnt even enabled.
What im using:
-Sloeber V4.2 as IDE
-Arduino Core V 2.3.0
-Jantje ESP Hardware debug 1.0
-ESP8266(ESP-01 Black version)

Here is the debugger console output:
GNU gdb (GDB) 7.11 Copyright (C) 2016 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 "--host=i686-pc-mingw32 --target=xtensa-lx106-elf". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://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". (trace) gdbarch_init() (trace) gdbarch_init() (trace) xtensa_unwind_pc (next_frame = 0x82c1e40) (info ) [xtensa_unwind_pc] pc = 0x4010025b (trace) xtensa_alloc_frame_cache () (trace) call0_analyze_prologue (start = 0x4010025b, pc = 0x4010025b, ...) (verb ) [call0_analyze_prologue] stopped at instr addr 0x4010025b, succeeded gdbstub_do_break_breakpoint_addr () at D:\sloeber\arduinoPlugin\packages\Jantje\hardware\esp8266\1.0.0\libraries\gdb\gdbstub-entry.S:399 399 break 0,0 Warning: the current language does not match this frame. (trace) xtensa_skip_prologue (start_pc = 0x40107038) (trace) xtensa_breakpoint_from_pc (pc = 0x4010703d) (trace) xtensa_skip_prologue (start_pc = 0x40107038) (trace) xtensa_breakpoint_from_pc (pc = 0x40107044) (trace) xtensa_skip_prologue (start_pc = 0x40106ff8) (trace) xtensa_skip_prologue (start_pc = 0x40106ff8) (trace) xtensa_breakpoint_from_pc (pc = 0x40106ffd) (trace) xtensa_breakpoint_from_pc (pc = 0x40106ffd) (trace) xtensa_breakpoint_from_pc (pc = 0x40106ffd) (trace) xtensa_breakpoint_from_pc (pc = 0x4010703d)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.