gdb break command

[Joerg]

need a gdb break command urgently!
to stop the program, not to stop debugging
I don't understand the usage of run and continue
in C::B,too.
Apart from that, remote debugging on ARM7
works not bad. 

[Jenna]

need a gdb break command urgently!
to stop the program, not to stop debugging

If you hit the stop-button (the red one with the white cross) once, the program should stop, not the debugging process.

In most cases you don't see the yellow triangle, because you are in a library without debugging symbols, but you can open the disassembly window, and in the Debugger Log you can see where you are.

You are now able to click (for example) "Step out" unless you are in code gdb can find the sources.
From this point you can debug as usual.

[mariocup]

Hi rekisum,

the debug interrupt button works under linux. If you hit stop the program will be interrupted and if you press again stop the debugger will be stopped. This does not work for windows. If you want to interrupt the debug process under windows there is only the workaround to send an user command to the debugger

Code

interpreter-exec mi interrupt 

Bye,

Mario

[Joerg]

Hi,

hitting the red button sends a 'quit' command to gdb.
I can see this in the Debugger (debug) window.

As I remotely debug my ARM7 I can see
Info: server.c:355 server_loop(): dropped 'gdb' connection in my OpenOCD info window.
(OpenOCD is a popular JTAG gdb server)

Mostly even that doesn't work and Codeblocks hangs with:
Trying to pause the running process...

I'm not able to send a user command when the debugger is running!?

What do you mean with 'the debug interrupt button works under linux' ?
I do remote debugging over JTAG with arm-elf-gdb / OpenOCD ..... under WinXP.

Bye

[martind]

Hi Rekisum,

I had the same problem. I tried various methods of sending ctrl-C interrupts to GDB but was unsuccessful. I found some code on the net that even injected code into GDB's process space to try and issue ctrl-C via software but no luck.

How CodeBlocks gets around this for Windows app debugging is to DebugBreak the process being debugged.

I am currently working on a plugin with OpenOCD, and I establish a telnet connection with OpenOCD (wxSocketClient) and send the "halt" command. It's fairly easy to do, and I have code if you want it.

I would not have thought that the "interpreter-exec mi interrupt" command would work in this case, as GDB goes modal when you continue? (send command to debugger is greyed out).

Also, on the MI note, perhaps changing to MI in the long term for CodeBlocks?


Martin.

[Joerg]

Hi martin,

How CodeBlocks gets around this for Windows app debugging is to DebugBreak the process being debugged.
I am currently working on a plugin with OpenOCD, and I establish a telnet connection with OpenOCD (wxSocketClient) and send the "halt" command. It's fairly easy to do, and I have code if you want it.

I will try to open a telnet console to OpenOCD.
If your plugin offers a new button sending a break it would be a nice workaround.

Also, on the MI note, perhaps changing to MI in the long term for CodeBlocks?

Ah, thats interesting.
So Codeblocks doesn't use MI to talk with GDB like Eclipse does?
I don't like Eclipse but remote debugging with the plugin from Zylin works, after all.
How is Codeblocks talking to GDB, and is this the reason why the break command
is not supported under windows?
Joerg

[martind]

Hi Joerg,

My plugin uses the existing halt button. The functionality of this button is if GDB is running, then pressing it will halt. If GDB has halted, pressing it will terminate debugging.

There are 3 messages that have been created for plugins:

cbEVT_DEBUGGER_STARTED
cbEVT_DEBUGGER_PAUSED
cbEVT_DEBUGGER_FINISHED

However, these do not appear to be implmented yet. I have modified debuggergdb.cpp to dispatch these 3 messages (would like to suggest method via patch soon). The plugin then picks this up and issues the "halt\r" command when it receives the paused message.

No MI interpreter is not used, the output of GDB is regex'd. Input is sent to GDB via console input stream. This means that when GDB is running, GDB is unresponsive to anything but signals (ctrl-C etc). That's why the break command does not work.

With MI, I believe the interpreter is running all the time? Havent used MI much so not an expert.

Eclipse is nice, but there are a few things that need changing. Adding / removing source files is my biggest bug-bear. Being Java is good for transparent cross platform, but slowish on older machines.




Martin.

[Joerg]

sending halt via telnet works
a 'halt' button would be very nice
Hopefully waiting for your plugin  ;-)

[thomas]

Hi,

hitting the red button sends a 'quit' command to gdb.
I can see this in the Debugger (debug) window.

That's funny, because what I see is this:
Child process PID: 3520
Trying to pause the running process...
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
Program received signal SIGTRAP, Trace/breakpoint trap.
In ntdll!DbgUiConnectToDbg () (C:\WINDOWS\system32\ntdll.dll)
Continuing...
Trying to pause the running process...
Program received signal SIGTRAP, Trace/breakpoint trap.
In ntdll!DbgUiConnectToDbg () (C:\WINDOWS\system32\ntdll.dll)

Maybe you're using a very old version, or you're hitting the wrong button?

[martind]

Hi Thomas,

Is this when you are debugging a windows / linux native executable?

Martin.

[Jenna]

It's on windows, on linux it's SIGINT.

[martind]

Hi Jens,

Ok so when you are debugging a windows program, the SIGTRAP signal occurs because a DebugBreakProcess Kernel32 call has been issued to the GDB child process (program being debugged), causing a debug exception. In this case, GDB receives this exception in the form of the SIGTRAP signal:

Code

long pid = m_State.GetDriver()->GetChildPID();

if (DebugBreakProcessFunc && pid > 0)
{
			Log(_("Trying to pause the running process..."));
			HANDLE proc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, (DWORD)pid);
			if (proc)
			{
				DebugBreakProcessFunc(proc); // yay!
				CloseHandle(proc);
				done = true;
			}
			else
				Log(_("Failed."));
		}

When you connect to a remote host e.g target remote localhost:2000 (in the case of OpenOCD), GDB does not have a child process. Therefore the DebugBreak mechanism is unsuitable in this case.

If you run pure GDB from the command line, to break GDB you can press ctrl-C. But I am unsuccessfull in doing this programatically.


Martin.

[starkeeper]

This annoying behaviour bothers me for at least two years now. And it doesn't seem to be fixed in the future, that is really frustrating.
And then there are these PC software gurus that don't stop to tell you that it works fine, when they hit the stop button. But none of them has even tried to debug a remote target.

This little neat "Bug" or missing feature makes codeblocks still unusable for embedded devlopement.

Btw. the arm-elf-insight debugger works fine, and the stop button really stops the target as expected.

[martind]

Thats because they use GDB MI.

[g2003p]

Good Day All!

I've found a partial solution to this problem, it works well for me. Not really found a method to send ctrl-C to the debugger process, but I did following change in DebuggerGDB::LaunchProcess:
    //m_Pid = wxExecute(cmd, wxEXEC_ASYNC, m_pProcess);
    m_Pid = wxExecute(cmd, wxEXEC_ASYNC | wxEXEC_NOHIDE, m_pProcess);
Now a console window appears when the debugger is started. If I hit the ctrl-C inside, the debugger breaks as expected....

Additionally, I changed behavior of start command to gdb, so that in case off remote debugging always continue and never run ist omitted.

If somebody is interested, I can post affected files etc. or a complete binary (trunk from 2008-09-12).

Gottfried