Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] gdbserver "attach" doesn't fully init the session?

> Thanks Marc for your detailed explanations. This helps a lot !

No problem, I think such discussions are essential to figure out the best way forward in general.

> Let’s assume that we want to move from our current approach (one gdbserver per process)
> to the daemon approach (one gdbserver –multi for all).
> Then the following questions come up:

> 1.       Only “non-stop mode GDB” is supported (we used stopmode so far, so I guess that’s why the “attach another” failed for me).

Yes, CDT does not support multi-process in non-stop.  Although probably do-able, I believe all-stop would limit multi-process debugging.

> a.       While stopmode is less powerful, I find it more intuitive for beginners. Can a breakpoint be configured in nonstop mode to stop more than its thread, ie behave like stopmode?

I guess you could set a GDB bp action to interrupt the whole process.  But I think this may be better addressed with the upcoming GDB feature "all-stop on top of non-stop" where the all-stop mode will be a specialization of the more general non-stop mode.

In your multi-session setup, you are effectively running all-stop for each process, but non-stop across processes (sessions).  It would be an interesting option to have for a single session.

> 2.       Can a keyboard shortcut be associated with the “connect another” green button ?

It's a normal commands, so sure.

> 3.       Is there API to programmatically “connect another” ?

In FinalLaunchSequence.java, we call the 'button' to trigger the first attach dialog to pop-up:

                IConnectHandler connectCommand = (IConnectHandler)fSession.getModelAdapter(IConnectHandler.class);
                if (connectCommand instanceof IConnect) {
                    ((IConnect)connectCommand).connect(requestMonitor);
                }

where fSession is the DsfSession.

> a.       Ideally passing PID, and local-process-path to the “connect another” routine.

The above triggers the UI to get the pid and path; if you have it already (also taken from FinalLaunchSequence.java and adding the parameter to the path):

                fProcService.attachDebuggerToProcess(
                        fProcService.createProcessContext(fCommandControl.getContext(), Integer.toString(pid)),
                        pathToBinary, // this is not part of a local attach as it is not needed
                        new DataRequestMonitor<IDMContext>(getExecutor(), requestMonitor));

where fProcService is the IGDBProcesses service, and
fCommandControl is the ICommandControlService service.

> 4.       Assume that we attach the gdbserver –multi session automatically when we connect the target.
> a.       Can we make sure that users cannot terminate this multi-attach that is meant to stay around?

CDT does not provide a way to kill that gdbserver.  It is really mean for daemons managed by the target.  So, as long as the user does not explicitly kill the gdbserver (which can be done from the eclipse gdb console by typing 'monitor exit'), CDT won't kill it.

> 5.       Have you heard about any risk of one broken debug session affecting the others ? (Multiple gdbs/gdbservers might seem safer than a single point of failure … when one breaks down, you just launch another, whereas a broken gdbserver –multi daemon would be a problem)

I have to admit that single-process debugging is more stable than multi-process debugging at this time.  Things keep improving, but the best way for that is to get more usage and testing.
An advanced target should handle the gdbserver agent dying and take charge is starting it again.

> The main issue that bugs us is still Bug 400033. It’s a pity that the team which started contributing ran out of time and was happy with their local fork thus not pursuing the contribution.

I was wondering why things stopped :)

> Right now we’re exploring synergies between tcf-agent (for getting the process list and path mapping) and gdb (for debugging on Linux). Thus we’d like to drive the attach via API … but of course we’d still like to end up with the technically best approach, and one that is safe for the future.

I think a good option, which we may have discussed before, I don't recall, is to extend GDB to have a mechanism to look for binaries on the host, like it does for libraries (or at least, I think that's what its for):

(gdb) help set solib-search-path
Set the search path for loading non-absolute shared library symbol files.
This takes precedence over the environment variables PATH and LD_LIBRARY_PATH.

I think we are close to a better solution, but someone has to tackle it.
I guess it hasn't been a big enough problem yet...

Marc
 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Khouzam
Sent: Friday, May 29, 2015 5:08 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] gdbserver "attach" doesn't fully init the session?

 

Hi Martin,

My answer has ended up being pretty long, but the Remote story is not simple.  I hope you can decipher my awkward explanation below.

Let me start by saying that the remote debug handling would benefit from some simplification. GDB has evolved a lot in the last few years and many of the things CDT used to need to do are no longer necessary.  A simple example is that GDB/gdbserver now allow to both attach to multiple processes, but also start multiple processes in the same session; this blurs the line between what CDT calls a "remote-attach" session vs the single process "remote" session.  That being said, lets deal with what CDT does now :)

> When I attach multiple processes through one gdbserver, is there any extra benefit compared to attaching multiple processes with one gdbserver each ?

The main reason is that some targets only provide a single instance of the debug agent, so GDB has to access all processes through that single agent.

But there are other advantages, such as:
- re-using a GDB that is already properly setup
- better caching for duplicated requests (we don't cache across debug sessions)
- a better contained representation of the target for global concepts (e.g. OS Resources view)
- allows for grouping and run-control on groups (this is coming to both CDT and GDB)
- etc

> For example, could I set a breakpoint in process A that would also stop process B ?

As you know, when you set a bp in Eclipse, it will affect all sessions, so if you run one session with multiple processes, or multiple sessions with one process each, the Eclipse breakpoints will affect everything.  On the other hand, if you were to set a breakpoint directly with GDB, then yes, it will affect all processes that under the control of that GDB only.

> The reasons why we’re not going with the green button multi-attach right now include
> -          Bug 400033 : In a Cross setup, it’s very awkward having to browse to the local exe path when the remote path could be mapped automatically

This would benefit from being improved, and you guys started working on that.
But I think that starting gdbserver pointing to a process, or pointing to that same process from Eclipse, technically requires the same knowledge of the location of that process from the user.

> -          Gdbserver lifecycle: One gdbserver –multi on the remote seems not sufficient. At least to me on Luna SR2 it’s unclear how to “add another attach” to an existing attached process (the green attach button is disabled after the initial attach). On the other hand, if Eclipse starts the gdbserver when does it die ?

The Automatic remote mode only supports single process debugging at this time.  This is what I was referring to above as old GDB limitations.  We could enable multi-process in that case with today's GDB.

To 'attach' to a 'gdbserver --multi' we have a different launch, which is not very visible as part of the "C/C++ attach to application" launch config type.  The FAQ tries to clarify this.  Please have a look at the "Remote attach launch" part of this page:
    https://wiki.eclipse.org/CDT/User/FAQ#How_do_I_debug_a_remote_application.3F
This remote mode does not start gdbserver so that it can be used to connect to targets that provide a debug agent as a daemon.

However, with some cleanup, we could improve the Automatic Remote launch to start gdbserver with the --multi flag (I believe Mikhail has a patch for that a while ago).  In that case, CDT would kill gdbserver when the user killed the entire launch, as compared to killing individual processes. 

Related to that, there is a preference that allows to keep a debug session alive, along with GDB, even when all debugged processes are gone (Preferences->C/C++->Debug->GDB->"Terminage GDB when last process exits").  The user can then stay connected to a target and attach/start new processes.

> -          Workflow: After running the “Attach Launch” it’s awkward having to click “Attach” again inside the debugger.

Maybe the approach CDT takes now is not the best.  The idea was that a user may want to inspect the target using GDB without actually attaching to a process (e.g., OS Resources view).  We could choose to automatically pop-up the attach dialog, as we do in the local attach case.  The user could even press Cancel on that dialog if that is not what they wanted.  If you feel this would be a better user experience, please open an enhancement bug.

> -          Consistency: “Run” Launches are started outside the debugger, but “Attach” is done inside the debugger

I'm not sure what you mean here.
Probably related, CDT/GDB now allows to both attach to many processes, but also to start multiple new ones, all in the same session.  Note the Debug's view menu action "Debug New Executable..." available when multi-process is supported (non-stop, remote-attach session).

I hope this helps, and I'd like to continue the discussion to help us find the path toward a simplified Remote launch experience for CDT.

Thanks

Marc


> How are others solving this ?
> Any comments / thoughts would be welcome.

> BTW, BIG BIG thanks to the whole CDT community for your responsiveness. I’m amazed time and again about your timely expert answers to my many questions J

> Thanks,
> Martin


Back to the top