Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Customizing GDB Launch

So how do I get the interrupt to send –exec-interrupt instead of ^C?

 

It seems like it is hard coded into the GDBBackend to send the ^C.

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Khouzam
Sent: Thursday, May 22, 2014 2:29 PM
To: 'CDT General developers list.'
Subject: Re: [cdt-dev] Customizing GDB Launch

 

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

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Phillips, Brandon
Sent: Thursday, May 22, 2014 12:27 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Customizing GDB Launch

 

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
Sent: Thursday, May 22, 2014 10:45 AM
To: 'CDT General developers list.'
Subject: EXTERNAL: Re: [cdt-dev] Customizing GDB Launch

 

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
Sent: Thursday, May 22, 2014 10:25 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Customizing GDB Launch

 

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
Sent: Tuesday, May 20, 2014 4:40 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Customizing GDB Launch

 

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
Sent: Tuesday, May 20, 2014 4:17 PM
To: CDT General developers list.
Subject: EXTERNAL: Re: [cdt-dev] Customizing GDB Launch

 

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
Sent: Tuesday, May 20, 2014 4:08 PM
To: 'CDT General developers list.'
Subject: Re: [cdt-dev] Customizing GDB Launch

 

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
Sent: Wednesday, May 07, 2014 4:42 PM
To: CDT General developers list.
Subject: [cdt-dev] Customizing GDB Launch

 

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.


Back to the top