[OT] unofficial MinGW GDB gdb with python released

[ironhead]

How is C::B attempting to 'pause' gdb.exe?

[ollydbg]

How is C::B attempting to 'pause' gdb.exe?

Read the source code of the Break() function. You will see it.

[ollydbg]

In the code:

Code

void DebuggerGDB::Break()
{
    // m_Process is PipedProcess I/O; m_Pid is debugger pid
    if (m_pProcess && m_Pid && !IsStopped())
    {
        long pid = m_State.GetDriver()->GetChildPID();
        if (pid <= 0)
            pid = m_Pid; // try poking gdb directly
    #ifndef __WXMSW__
        // non-windows gdb can interrupt the running process. yay!
        if (pid <= 0) // look out for the "fake" PIDs (killall)
            cbMessageBox(_("Unable to stop the debug process!"), _("Error"), wxOK | wxICON_WARNING);
        else
            wxKill(pid, wxSIGINT);
    #else
        // windows gdb can interrupt the running process too. yay!
        bool done = false;
        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."));
        }
    #endif
        // Notify debugger plugins for end of debug session
        PluginManager *plm = Manager::Get()->GetPluginManager();
        CodeBlocksEvent evt(cbEVT_DEBUGGER_PAUSED);
        plm->NotifyPlugins(evt);
	}
}

The main task is call the DebugBreakProcessFunc function. Which is defined by :

Code

    kernelLib = LoadLibrary(TEXT("kernel32.dll"));
    if (kernelLib)
        DebugBreakProcessFunc = (DebugBreakProcessApiCall)GetProcAddress(kernelLib, "DebugBreakProcess");
    #endif
}

Also, you can find a stand alone program in this page:

http://cygwin.com/ml/cygwin/2006-06/msg00321.html

or

http://forums.codeblocks.org/index.php?topic=8577.0

or

http://www.nabble.com/GDB-Ctrl-C-Break-td1782635.html

or

http://forums.codeblocks.org/index.php/topic,7964.msg59677.html#msg59677

[ironhead]

As posted in this message:

http://forums.codeblocks.org/index.php/topic,7964.msg61123.html#msg61123

Wouldn't sending a:

Code

mi interrupt

Make the most sense, since it works cross platform and uses the GDB internals as opposed to relying on a win32api call that only exists in XP and above?

[ollydbg]

As posted in this message:

http://forums.codeblocks.org/index.php/topic,7964.msg61123.html#msg61123

Wouldn't sending a:

Code

mi interrupt

Make the most sense, since it works cross platform and uses the GDB internals as opposed to relying on a win32api call that only exists in XP and above?

I personally think this command make no sense, because when the debuggee is running, GDB.exe  can't accept any command.

[ollydbg]

Hi, all, I just find some more issue of gdb.exe 7.0, it seems that gdb.exe 7.0 can't set breakpoint in a DLL's source file, but gdb.exe 6.8.3 can.

Here is the test project, it contains two target, one is a exe, and one is a dll, then, the exe will call a function in the dll.

You can set breakpoints in both exe and dll, but for gdb.exe 7.0, only breakpoints in exe file can be reached.




[attachment deleted by admin]

[nanyu]

You can set breakpoints in both exe and dll, but for gdb.exe 7.0, only breakpoints in exe file can be reached.

And I found the program didn't step into the function where from a DLL project when I press Shift+F7 ...

[ollydbg]

You can set breakpoints in both exe and dll, but for gdb.exe 7.0, only breakpoints in exe file can be reached.

And I found the program didn't step into the function where from a DLL project when I press Shift+F7 ...

So, this means gdb 7.0 treats dll file badly.

[theOcelot]

Switching to TDM g++ on one of my installations seems to have fixed it for good. I'll see about switching my main comp to TDM, if they don't put this fix in the official MinGW pretty soon.

[Jenna]

It works for me. (TDM-GCC 4.4.0 and GDB 7.0 from the above link)

However I also noticed something strange.

Tooltipped during debugging on an std::string (local variable).  [the ..... mean there is more stuff there]

Code

ContinueDebugEvent .......
gdb : kernel event for pid= ..... ... code=EXCEPTION_DEBUG_EVENT
ContinueDebugEvent ....
gdb : kernel event for pid= ..... ... code=EXCEPTION_DEBUG_EVENT
"Group"

Notice the "Group" at the end, the correct value of the string.

With another string it is ok.

The cause for the flood of (visible) ContinueDebugEvent's is that the gdb startline has changed from GNU gdb x.x.x to GNU gdb (GDB) x.x.x.
The additional (GDB) breaks our code to determine the gdb major- and minor-version and that breaks the code that determines the child-pid's of gdb.
After fetching the child-pid we no longer parse lines that start with ContinueDebugEvent.

I think we could use a regex here to filter out the version number, to avoid such problems inth future.

here is patch that can do that:

Code

Index: gdb_driver.cpp
===================================================================
--- gdb_driver.cpp	(Revision 5861)
+++ gdb_driver.cpp	(Arbeitskopie)
@@ -861,7 +861,13 @@
             // it's the gdb banner. Just display the version and "eat" the rest
             m_pDBG->Log(_("Debugger name and version: ") + lines[i]);
             // keep major and minor version numbers handy
-            wxString major = lines[i].Right(lines[i].Length() - 8);
+            wxRegEx re(_T("([0-9.]+)"));
+            if (!re.Matches(lines[i]))
+            {
+                m_pDBG->Log(_T("Unable to determine the version of gdb"));
+                break;
+            }
+            wxString major = re.GetMatch(lines[i],0);
             wxString minor = major;
             major = major.BeforeFirst(_T('.')); // 6.3.2 -> 6
             minor = minor.AfterFirst(_T('.')); // 6.3.2 -> 3.2

It does not fix the main problem (can not set breakpoints in some files and libs) of course, but that appears to be a gdb-issue.

[ollydbg]

Continue the "breakpoint" problem.
From the mingw user mail list, I found that post below mine

>> B: I found that the GDB.exe 7.0 *can't* set breakpoints on an DLL's
>> >> source file.
>> >>
>> >> For example I have A.cpp->A.exe and B.cpp->B.dll.
>> >>
>> >> Then A.exe depend on the B.dll.
>> >>
>> >> When I debug A.exe, I *can* set breakpoints in A.cpp, but I *can't* set
>> >> breakpoints in B.cpp.
>> >>
>> >> In GDB.exe 6.8.3, breakpoints can set in both A.cpp and B.cpp.
>> >>
>> >> I have added the test code in C::B forum post:
>> >> http://forums.codeblocks.org/index.php/topic,11301.msg77123.html#msg77123
> >
> > I'll take a look at this in a couple of days, since I'm swamped with
> > other stuff at the moment.  I'll let you know how I make out...

I managed to find a little time to test debugging a DLL and I was able
to do so with GDB.  Here's the steps I ran:

1.  Compile both the 'exe' and 'dll' with debug symbols
2.  Run 'gdb'
3.  From the (gdb) prompt type 'file [library name].dll'
4.  From the (gdb) prompt type 'break [library source file].cpp:[line number]'
5.  From the (gdb) prompt type 'exec-file [executable name].exe'
6.  From the (gdb) prompt type 'run'

As expected, gdb stopped at the line number in the library source file.

So from a GDB standpoint, it is behaving as expected and it can set
breakpoints on DLLs and actually hit them.  I'll grab the latest C::B
nightly Tuesday (unfortunately I won't have the time tomorrow to test
it) and see how it goes about debugging a library.

Cheers!

Chris

So, it seems in the now gdb 7.0, we should manually send command 'file [library name].dll' . I think currently, this haven't done in the C::B's debugger plugin.

[oBFusCATed]

Yes it is not done and I'm not sure if it can be done easily...

[ollydbg]

Hi ollydbg,

I had a similar problem with ARM gdb that I build myself under windows. In the gdb sources there was a bug in getting the relative path for setting breakpoints. After putting the following code in the file util.c it worked also under windows. The strange thing is that the binary version of gdb 6.8 worked without changes for x86.

hello, the source file was "utils.c" not "util.c" 

Also, I have successfully built the gdb.exe under TDM-GCC 4.4.1 and MSYS system.

[ollydbg]

I just find more bugs of GDB.

Follow the steps

 Here's the steps I ran:

1.  Compile both the 'exe' and 'dll' with debug symbols
2.  Run 'gdb'
3.  From the (gdb) prompt type 'file [library name].dll'
4.  From the (gdb) prompt type 'break [library source file].cpp:[line number]'
5.  From the (gdb) prompt type 'exec-file [executable name].exe'
6.  From the (gdb) prompt type 'run'

I still can't load the dll file. here is the Debug log:

Code

> file "F:\cb_svn\src\devel\share\CodeBlocks\plugins\codecompletion.dll"
F:cb_svnsrcdevelshareCodeBlockspluginscodecompletion.dll: No such file or directory.
>>>>>>cb_gdb:
> file codecompletion.dll
codecompletion.dll: No such file or directory.
>>>>>>cb_gdb:

 

[nenin]

You can try like this:

Code

file F:/cb_svn/src/devel/share/CodeBlocks/plugins/codecompletion.dll