[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, 3 months ago by Florian.

[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,

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.

[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.

[Author]

Posts