Author Topic: external gdb can't stop  (Read 188 times)

dunkers

  • Senior Community Member
  • Posts: 720
  • Hero Points: 29
external gdb can't stop
« on: September 20, 2020, 04:23:19 am »
I am trying to use SE to debug running app on an ESP32 via JTAG:

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/jtag-debugging/index.html

The CPU is dual-core so requires a custom gdb. I have set up SE to use this via the 'Attach to remote process (GDB)' and it connects OK. I can even use the debug toolbar single-step commands (next, step in, step out) and read variables.

However, I can't use continue nor halt. Pressing the 'run' button seems to do nothing (it may be running on the target - can't tell) and, of course, the only option then is to press pause, but doing so don't actually pause anything and on the OpenOCD display I get:
Code: [Select]
Warn : ignoring character 0xffffffff
Warn : ignoring character 0xfffffff3
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1060). Workaround: increase "set remotetimeout" in GDB

Only option then is to exit debugging and restart.
If I do this via the (same executable) gdb command line it works fine. 'c' gets things running, '^c' stops, so it's not the gdb flavour, I think.

There are some other issue which may or may not be related. The gdbinit which I pass should cause the app to reset then run up to main() and halt. Manually driving gdb it does, but in SE it just halts the CPU and wherever it is is what comes up in the debug window.

Is this likely to be a user error (i.e. something not set up right)?

edit: it's the suspend that's a problem - 'continue' does let it run OK.
« Last Edit: September 20, 2020, 05:00:00 am by dunkers »

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3076
  • Hero Points: 449
Re: external gdb can't stop
« Reply #1 on: September 21, 2020, 04:10:49 pm »
Are you on Windows or Unix ?

If you are on Windows, do you have the GDB remote proxy option enabled or disabled (Debug > Debugger Options...)?

dunkers

  • Senior Community Member
  • Posts: 720
  • Hero Points: 29
Re: external gdb can't stop
« Reply #2 on: September 21, 2020, 05:18:19 pm »
Windows, and remote proxy was enabled (albeit without a port specified). I turned it off and didn't notice any difference.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3076
  • Hero Points: 449
Re: external gdb can't stop
« Reply #3 on: September 21, 2020, 07:36:46 pm »
Do the following to get a log of the debugger interactions:

1) Macro > Set Macro Variable... > def_debug_logging = 1

2) Start your debug session, and do what you do to reproduce the problem.  Try to get there in the minimum number of steps.  Be sure to include a Debug > Debugger Information... in the sequence so I can see what version of GDB you are using.

3) Stop the debug session.

4) In your configuration directory, under "logs/debug.log", you'll find a log of all the commands sent to GDB and the replies.  Post that.

5) Remember to turn logging back off.   Macro > Set Macro Variable... > def_debug_logging = 0


Your observations about what GDB does from the command line are helpful, but unfortunately, GDB's command line behavior has very little to do with how it works over the machine interface (MI). 

dunkers

  • Senior Community Member
  • Posts: 720
  • Hero Points: 29
Re: external gdb can't stop
« Reply #4 on: September 21, 2020, 09:13:18 pm »
Quote
GDB's command line behavior has very little to do with how it works over the machine interface (MI)

OK. Thought it was the same data, just different source/destination :)

Quote
a log of all the commands sent to GDB and the replies.  Post that.

Attached.


Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3076
  • Hero Points: 449
Re: external gdb can't stop
« Reply #5 on: September 21, 2020, 11:39:29 pm »
Could you post the .gdbinit that you are using.  Are you putting GDB into non-stop mode (set non-stop ...)?

dunkers

  • Senior Community Member
  • Posts: 720
  • Hero Points: 29
Re: external gdb can't stop
« Reply #6 on: September 22, 2020, 09:30:00 am »
gdbinit:

Code: [Select]
set remote hardware-watchpoint-limit 2
mon reset halt
flushregs
thb app_main
c

But that seems not to be recognised since it comes up stopped at some seemingly arbitrary location rather than app_main (the 'main' for this type of dev).

Er... non-stop... not specifically, and looking at openocd output it says both CPUs are stopped when it halts, so I suspect not via other means either.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3076
  • Hero Points: 449
Re: external gdb can't stop
« Reply #7 on: September 22, 2020, 02:14:35 pm »
The commands in your .gdbinit are definitely recognized.  You are setting a one-time hardware breakpoint at app_main, so no surprise it emerges stopped there.

Still no idea why GDB does not handle the -exec-interrupt command correctly in your case.  I've seen numerous threads about the workarounds Eclipse does for various versions of GDB and remote targets.  Not being 10,000 people, I generally tend to gravitate to a more elegant approach, but that depends on GDB *doing*what*I*ask*it*to*do !!!

Do you have the option of trying another version for your custom build of GDB, like 8.3 or 7.9, this could just be a singularity in the 8.1 version.

dunkers

  • Senior Community Member
  • Posts: 720
  • Hero Points: 29
Re: external gdb can't stop
« Reply #8 on: September 22, 2020, 02:34:50 pm »
Quote
You are setting a one-time hardware breakpoint at app_main, so no surprise it emerges stopped there.

That's the point - it doesn't emerge stopped there. It's stopped somewhere else.

Having said that, I just tried it now to note exactly where it is coming up, and the damn thing emerged stopped at app_main()! Just once, though. Second time it came up paused in the idle hook (asm "waiti 0").

The particular gbd is provided by the chip manufacturer - I'll see if there's a different version to be had. Also trying to configure Eclipse to check if that has a similar problem.