| Re: [cdt-dev] Customizing GDB Launch |
|
Try to set a breakpoint in DsfSuspendCommand#executeSingle() and follow the call to getRunControl().suspend() to see what gets called. It should be GDBRunControl_7_0_NS#suspend, which sends –exec-interrupt.
If it is not, you will need to check how your DSF RunControl services is instantiated. From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Joseph Henry Even if I enable non-stop mode, a pause does not work.
In the debug output I see the following so, I know non-stop mode is being used: 447,014 [MI] (gdb) 447,014 [MI] 13-gdb-set target-async on 447,016 [MI] 13^done 447,016 [MI] (gdb) 447,016 [MI] 14-gdb-set pagination off 447,019 [MI] 14^done 447,019 [MI] (gdb) 447,019 [MI] 15-gdb-set non-stop on 447,022 [MI] 15^done But when I let the process run from the debugger and then press pause, I get this: !ENTRY org.eclipse.cdt.dsf 4 10005 2014-05-22 14:17:28.842 !MESSAGE Request for monitor: 'RequestMonitor (org.eclipse.cdt.dsf.concurrent.RequestMonitor@3ca22c87): Status ERROR: org.eclipse.cdt.dsf.gdb
code=10004 Interrupt failed. null' resulted in an error. !SUBENTRY 1 org.eclipse.cdt.dsf.gdb 4 10004 2014-05-22 14:17:28.842 !MESSAGE Interrupt failed. Even with non-stop mode, it is still trying to execute the interrupt with the Cntrl-C From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Marc Khouzam A little more info about the non-stop comment. GDB has a way to communicate asynchronously with the target (set target-async on). Using this setting allows to keep the GDB prompt available all the time[*], which is what removes the need to use ^C. We use that mode for non-stop (is it a pre-requisite for non-stop) but, although it can be used for all-stop, CDT does not use it.
There are a couple of hurdles to get that working, for example, GDB on Windows didn’t support that mode a while ago (I don’t know if it does now). But we could allow for target-async to be a preference, so that when it works, CDT uses it all the time. I would love to see that happen for CDT! Bug 304721 - Use GDB async mode for GDB 7.0 Marc From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Phillips, Brandon That sounds nice, hopefully it works for him (and us, when I revisit this!). My approach was a big hack that modified starter.exe’s interrupt strategy when it recognzed the process was ssh-gdb. The goal is just to send a PLEASE_INTERRUPT string to gdb-ssh’s stdin that is recognized on
the remote side by a perl wrapper around gdb. It’s even uglier than it sounds because of the way starter.exe hooks up the input from grandparent to child, which required an extra pipe and a thread to pump between them… (But it was a nice proof of concept
for us, that gdb-over-ssh under Eclipse can work fine.) If anybody is wondering, the motivation for gdb-over-ssh instead of using gdbserver stems from security policy. Security people hate open ports, and sometimes even forbid ssh client port forwarding. From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Marc Khouzam As a note, with non-stop, we don’t need to use an interrupt but send –exec-interrupt. So that should work for you out of the box when using non-stop mode. From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Joseph Henry Ok, So I tested this, and you are right, the interrupt is not sent correctly. How did you get this working? From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Phillips, Brandon How does this approach handle interrupting the remote process to wake up GDB (for manual pause, setting new breakpoints, etc)? When I glued together a gdb-over-ssh scheme for Eclipse, I ended up having to modify starter.exe to send a string command that triggered my gdb wrapper on the other side to interrupt the target process. (Not
pretty.) From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Joseph Henry I was able to get this working by following some of the documentation listed in:
http://wiki.eclipse.org/CDT/cdt-debug-dsf-gdb-extensibility and
http://wiki.eclipse.org/CDT/User/FAQ#How_can_I_choose_another_debugger_integration_for_CDT.3F Thanks, Joseph Henry. From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Marc Khouzam Hi, we don’t use extension points in DSF (yet?) As usual though, the way to extend things is to override one or more of the DSF services. In this case, the IGDBBackend service was added to help do what you want. By overriding this interface, you should be able to properly handle a GDB session launched over ssh. Marc From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Joseph Henry Hi guys, I want to be able to customize the gdb launch to invoke gdb over ssh instead of locally. I found this bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=240092 and it seems that this bug fix adds the functionality that I need, but I don’t really know where to start. Is there an extension point that I use in order to provide my own GDBBackend implementation? Thanks, Joseph Henry. |