Forgot to address the [*]
J
[*] When using target-async, GDB allows the user to use asynchronous commands or synchronous ones. So, the user can do ‘continue’ which will lock GDB (no prompt) as before, but if the user does ‘continue&’ then
GDB will keep accepting commands. Notice the similarity with a foreground/background job in a shell. So the user has to pay attention to that. For MI, which is used by CDT, all commands are in the background/asynchronous.
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Marc Khouzam
Sent: Thursday, May 22, 2014 1:22 PM
To: 'CDT General developers list.'
Subject: Re: [cdt-dev] Customizing GDB Launch
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
http://eclip.se/304721
Marc
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.
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.
Ok,
So I tested this, and you are right, the interrupt is not sent correctly.
How did you get this working?
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.)
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.
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
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.
|