VisualGDB and Non Stop Mode: Need to replace Ctrl-C?

[Florian]

I’m currently trying to use VisualGDB in Non Stop Mode (see https://sourceware.org/gdb/onlinedocs/gdb/Non_002dStop-Mode.html).

I added the following to the GDB start-up commands to switch to Non Stop Mode before attaching to my target.

set target-async
set non-stop
set displaced-stepping off
set pagination off

I have found that I can’t do an

-exec-continue

after the attach (because attach will stop all non-system processes and exec-continue will only run the actual selected thread), but that I have to do an

continue -a

My biggest problem at the moment is, that VisualGDB issues at several occasions a Ctrl-C (e.g. for Break-All or when setting a Breakpoint) at the GDB client it’s running in the background.

But I have to do an

interrupt -a

call instead.

So I’m wondering two points:

• Is there some VisualGDB configuration switch I’ve missed for Non Stop debugging mode? And/Or what I’m doing with the GDB start-up commands is wrong?
• Is there a possibility to exchange Ctrl-C by another GDB command? I’ve only seen the option to use Ctrl-Break instead of Ctrl-C under the Debug settings section.

So my best guess at the moment is that there is something in the VisualGDB extensibility interface that I can make use of.

Thanks in advance for any hints.

[support]

Hi,

Last time we checked the GDB non-stop mode, it was not very reliable and many commands did not work in it. Could you please let us know what are you trying to accomplish with using the non-stop mode? There could be a better solution to that.

[Florian]

Hi,

I would appreciate any solution that covers the following scenario: our developers want to set a breakpoint without knowing in advance which thread will trigger it nor do they want to stop all non-system threads in the target system.

So if any thread will hit the breakpoint, only this thread should be intercepted. We have a lot of external data source connected to our hardware and it would very fast lead to a fatal error not serving/answering them.

And it is a very convenient workflow – e.g. for generic code parts – not having to know the threads id/name in advance.

Attaching to the whole system with setting the non-stop debugging mode before seemed to be the way to accomplish this.

We are running the following GDB version:

GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "--host=i386-mingw32 --target=arm-ose".

For bug reporting instructions, please see:

.

It is a specialized GDB 7.4 ARM for our target’s OS.

The error I’m getting when trying to set a breakpoint or doing a break-all while in non-stop mode is the following:

Quit (expect signal SIGINT when the program is resumed)

Best regards,

Florian.

[support]

Hi,

Are you able to use the non-stop mode reliably in the normal command-line mode without VisualGDB?

[Florian]

Hi,

yes, it works fine in command line mode. But I had to start the GDB client with “-n” option and never found out the reason for having to prevent running the start-up scripts (I don’t have start-up scripts defined, so I was assuming some of the pre-defined start-up commands are intervening with non-stop debugging).

And it works with VisualGDB, if I run the “continue -a” command manually after attaching to the system. Then breakpoints are hit (if they are set before attaching to the system), stepping can be done and letting the thread run again also works.

I just can’t e.g. set/remove breakpoints in Visual Studio/VisualGDB while attached to the target (the Ctrl-C problem described above). But I can set or remove breakpoints via the command line interface. In non-stop mode it doesn’t seem necessary to break into the target when running e.g the “-break-insert” command.

So the solution I’m searching for is more like an option to change Ctr-C/do-something/continue sequences into just do-something.

And yes, it would be great if you could take a look again at a support for non-stop debugging build into VisualGBD. I don’t see any major problems in using the non-stop debugging mode.

Thanks for considering.

Best regards,

Florian.

[support]

Hi,

Please try this build: http://visualgdb.com/tmp/VisualGDB-4.3.10.230.msi
First go to the Custom Debug Steps page and set the break-in method to the “interrupt” command. Then save your settings, open the .vgdbsettings file in a text editor and set the following fields:

true

true

Let us know if that works for your setup.

[Florian]

Hi,

thanks a lot. That works like a charm 🙂 .

I can now e.g. insert/remove break points while attached.

One point I’ve recognized: if a thread hits a breakpoint, this thread gets to be the active thread. Meaning, if I let this thread run again and later hit “Break All” this last active thread will be intercepted. And only this thread.

I don’t have a problem with this, but maybe – if non-stop debugging is going to be officially supported by VisualGDB – it should be also configurable what the “Break All” should do in the non-stop debug context.

Best regards,

Florian.

[Florian]

Hi,

I just wanted to add, that I’ve found the problem with the “Break All” command.

The VisualGDB version 4.3.10.230 you have referenced/provided in one of your previous posts is sending

-exec-interrupt -a

But it should be

-exec-interrupt --all

Using -a will not do a “break into all”. It seems this invalid – or undocumented – option is silently ignored.

See also https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Program-Execution.html#GDB_002fMI-Program-Execution :

“In non-stop mode, only the context thread is interrupted by default. All threads (in all inferiors) will be interrupted if the ‘–all’ option is specified.”

Could you please fix this and provide an update or integrate it into the next official build?

Thanks in advance.

Best regards,

Florian.

• This reply was modified 9 years, 2 months ago by Florian.

[Author]

Posts