Author Topic: "debug_suspend" command  (Read 4866 times)

msr

  • Community Member
  • Posts: 8
  • Hero Points: 1
"debug_suspend" command
« on: July 28, 2008, 11:10:51 pm »
The "debug_suspend" command results in the following:

"Error suspending debugger:  Timeout out waiting for response from GDB."

Can someone tell me what this command generates so I can try to fix my version of GDB?

Thanks in advance!

-Mike


hs2

  • Senior Community Member
  • Posts: 2738
  • Hero Points: 288
Re: "debug_suspend" command
« Reply #1 on: July 28, 2008, 11:53:42 pm »
Documentation says that this command tries to suspend all threads of the debuggee. If this helps a bit...
HS2

msr

  • Community Member
  • Posts: 8
  • Hero Points: 1
Re: "debug_suspend" command
« Reply #2 on: July 29, 2008, 03:40:48 am »
Thank you...  I've tried to trap SIG_INT, ctrl-c, ctrl-break without luck.  I'd like to know exactly what is happening.

hs2

  • Senior Community Member
  • Posts: 2738
  • Hero Points: 288
Re: "debug_suspend" command
« Reply #3 on: July 29, 2008, 08:17:05 am »
It's helpful for the SlickTeam and others if you'd post some further details about your use case (SE version, gdb used, local/remote debugging, host/target platform, etc.).
HS2

msr

  • Community Member
  • Posts: 8
  • Hero Points: 1
Re: "debug_suspend" command
« Reply #4 on: July 29, 2008, 06:53:33 pm »
OK...

* I am using SlickEdit Version 13.0.1.0
* I am running on Windows XP
* I am cross compiling/debugging an embedded target, using "target remote ..."
* Target platform is Luminary Stellaris ARM Cortex board.
* I am using CodeSourcery gnu tools.

I rebuilt gdb just to translate the command "-exec-run" into "-exec-continue" because the "-exec-run" command causes the error:  "Don't know how to run, try help target."

When I pressed the pause button, or use "debug_suspend", it times out waiting for gdb.  It is as though gdb doesn't recognize that anything happened.  I would like to know more precisely what SlickEdit is doing.

I wrote a windows program to sit between Slickedit and GDB.  (It spawns GDB as a child process.)  That way I can log all communication between slick edit and GDB.  Under this scenario, "debug_suspend" doesn't seem to generate any communication between Slickedit and GDB, yet it does generates an exception in GDB.  I can't seem to trap anything in my program, which was invoked from SlickEdit, yet somehow GDB (which my program spawned) gets an exception from SlickEdit and exits?!  (I'm not sure how that is possible.)

Any ideas are appreciated!!

-Mike

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2831
  • Hero Points: 429
Re: "debug_suspend" command
« Reply #5 on: July 29, 2008, 09:01:33 pm »
First, if you want to log transactions between SlickEdit and GDB, just turn on def_debug_logging, as has been discussed before here on the forum.

Normally (local debugging), we find the child process running under GDB and send a break to it.  The program that you inserted between SlickEdit and GDB is causing us to follow what would otherwise be an impossible code path (remote debugging, but GDB has a child process).  I am putting a fix into the next release so that we will not be fooled so easy, but that is a separate issue.

With remote debugging, to cause a suspend, we found the only way was to put a proxy between GDB and the remote debug server, we then send a message to the proxy which in turn sends a break command to the remote server, and then we get a stop event if everything goes correctly.  You may need to verify that your remote gdbserver expects the same command to suspend as the standard linux gdbserver.

Why don't we send a "-gdb-interrupt" command to GDB instead of all this garbage?  Well, because "-gdb-interrupt" wasn't implemented initially with GDB/MI.  And secondly because GDB/MI, even in remote debugging mode, did not properly support asynchronous commands.  Recent release notes suggest that the async mode has been finally implemented as of GDB 6.8, but we have not had the opportunity to test it, and, in addition we still need to work with older versions of GDB.