Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Remote debugging and live execution

So, a little bit of history:

Originally, GDB only supported all-stop mode and its communication was synchronous.
What that meant was that when a thread was running, all threads were running, and
communication with GDB was blocked.  CDT could only ask info from GDB when
threads were suspended.  This explains why most requests from views are ignored
when threads are running.

Later on, GDB started supporting non-stop mode and an asynchronous communication.
This allows CDT to send queries to GDB, even when one or more or all threads are running.
As you've mentioned, not all queries make sense when the target is running, but some do.
For example, if you open the OS Resources view, it will remain responsive even when
all threads are running when in non-stop mode.
There hasn't been a directed effort to deal with each situation smartly, but it would be
very nice to go ahead with such an effort.

Some things to note:
- Blocking the use of commands when threads are running is normally handled by the use
  of the CommandCache class through methods setContextAvailable(..) and isTargetAvailable(..)
- although GDB now supports all-stop with an asynchronous communication, CDT has not made
  use of that; so when in all-stop mode, we still use synchronous communication and cannot
  send any queries to GDB when the target is running.  CDT could be enhanced to use
  async communication even in all-stop mode.

Feel free to open a bug.  
If someone steps up to start the work, I'm convinced the community will help out.

Thanks

________________________________________
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Flynn, Stephen [Stephen.Flynn@xxxxxxx]
Sent: June 27, 2016 9:58 AM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Remote debugging and live execution

> Hi Stephen,
>
> It sounds sensible to me to ease the flow of having some information that is
> showing for the "most applicable" context when no relevant debug context
> is actually active.
>
> It would be worth considering how it may interact and/or reuse
> implementation details of "pinned" contexts for views?
>
> Have you started working on such a patch? Are you looking for guidance on
> how to add such functionality?

I will not be able to dedicate any time in the near future to this.  I did want to start a conversation, and based on community feedback submit a bug.


>
> Jonah
>
> ~~~
> Jonah Graham
> Kichwa Coders Ltd.
> www.kichwacoders.com
>
>
> On 24 June 2016 at 17:24, Flynn, Stephen <Stephen.Flynn@xxxxxxx> wrote:
> > From my post to the CDT forum:
> >
> > Hello all,
> > I have been developing a plugin for Eclipse CDT for my company for the
> past several years. One of the things that has given me headaches is that
> most debug views are not active unless the current context is a suspended/
> stopped thread or a trace frame. All the while, commands sent via the
> console are easily handled by the gdbserver/stub.
> >
> > This may have made sense years ago, and still makes sense for particular
> views (Registers View comes to mind). But for the majority of views that rely
> on information retrieved from the remote target this information is available
> whether or not the context is in a suspended state.
> >
> > My questions: Is the current paradigm employed by Eclipse for debugging
> remote targets too restrictive in allowing views to be populated by
> information readily available from the remote target? Is this something
> worth submitting a bug report for?
> >
> > Stephen Flynn
> >
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or
> > unsubscribe from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top