Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Should gdb default non-stop mode debugging?

> From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Marc-André Laperle <marc-andre.laperle@xxxxxxxxxxxx>
> Sent: January 31, 2017 15:54
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Should gdb default non-stop mode debugging?
>  
> Just to make sure I understand:
> All-stop: means that all threads will stop whenever one stops (when a breakpoint hits for example)
> Non-stop: threads can be stopped individually, (when a breakpoint hits the other threads continue)

Right.

> Aside from that, are there any differences (benefits?) to non-stop vs all-stop?

I think that is all from a user point-of-view.
 
> Things I know of:
> - Reverse debugging does not work with non-stop

Correct.

> - Debug forked processes does not work with all-stop

So, multi-process is not supported in all-stop by CDT.
I think it is something we could do, but we don't at the moment.
Because of that, debug forked processes won't work, although
with a different GDB setting that CDT does not expose, we could
replace the parent process with the child, which would keep
it at one process being debugged, so should work in all-stop.
But I'd prefer looking into supporting multi-process in all-stop.

> One thing to consider if the default is changed: existing launch configs with Reverse debugging turned on will break. Right?
> I think it would be good if things could be a bit more automatic so that the user gets the best experience by default, i.e. non-stop if available, etc.

I like that concept.  Maybe we could query the target and if non-stop is supported, then we turn it on.
We'll need to change the preference to allow the user to choose between: "all-stop" and "non-stop if available"
And we'll have to handle the reverse debugging case somehow.
I've opened http://eclip.se/511419 if someone is interested in investigating this.

Good suggestion. Thanks!

Marc

> Marc-André
> From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
> Sent: Tuesday, January 31, 2017 1:41:32 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Should gdb default non-stop mode debugging?
>  
> Windows and Mac don't support non-stop.
> Specific embedded targets also may not support non-stop.
> 
> There is a preferences 
>     C/C++->Debug->GDB => "Non-stop mode"
> that the user can enable so that non-stop is selected by default
> for each new launch.
> 
> All-stop works all the time.
> So, although I always run non-stop, it is probably safer to leave
> the default to all-stop, and let users that understand the difference
> enable it.
> 
> Marc
> 
> From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Jeff Johnston <jjohnstn@xxxxxxxxxx>
> Sent: January 31, 2017 13:35
> To: CDT General developers list.
> Subject: [cdt-dev] Should gdb default non-stop mode debugging?
>  
> Is there any reason for not defaulting the CDT debugger to use non-stop debugging these days (i.e.
> are there known gdb implementations out there supported by CDT that don't support non-stop mode)?
> If there are good reasons, should the default be based on the gdb version or platform?
> 
> This came up as a Fedora bug so I thought I would ask the CDT Debug experts to see if the default
> is set the way it is for more than historical reasons.
> 
> -- Jeff J.


Back to the top