Author Topic: [OT] unofficial MinGW GDB gdb with python released  (Read 254097 times)

Offline ironhead

  • Almost regular
  • **
  • Posts: 210
Re: [OT] MinGW GDB 7.0 is released
« Reply #30 on: October 10, 2009, 01:47:58 pm »
How is C::B attempting to 'pause' gdb.exe?

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: [OT] MinGW GDB 7.0 is released
« Reply #31 on: October 10, 2009, 01:51:56 pm »
How is C::B attempting to 'pause' gdb.exe?
Read the source code of the Break() function. You will see it.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: [OT] MinGW GDB 7.0 is released
« Reply #32 on: October 10, 2009, 02:27:44 pm »
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
« Last Edit: October 10, 2009, 03:38:32 pm by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ironhead

  • Almost regular
  • **
  • Posts: 210
Re: [OT] MinGW GDB 7.0 is released
« Reply #33 on: October 10, 2009, 04:36:04 pm »
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?

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: [OT] MinGW GDB 7.0 is released
« Reply #34 on: October 10, 2009, 05:09:03 pm »
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.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: [OT] MinGW GDB 7.0 is released
« Reply #35 on: October 11, 2009, 03:40:42 am »
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]
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline nanyu

  • Almost regular
  • **
  • Posts: 188
  • nanyu
Re: [OT] MinGW GDB 7.0 is released
« Reply #36 on: October 11, 2009, 06:04:26 am »

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

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: [OT] MinGW GDB 7.0 is released
« Reply #37 on: October 11, 2009, 06:14:38 am »

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. :(
« Last Edit: October 14, 2009, 05:35:28 pm by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline theOcelot

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: [OT] MinGW GDB 7.0 is released
« Reply #38 on: October 11, 2009, 06:40:59 am »
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.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: [OT] MinGW GDB 7.0 is released
« Reply #39 on: October 11, 2009, 11:01:59 pm »
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.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: [OT] MinGW GDB 7.0 is released
« Reply #40 on: October 12, 2009, 01:25:30 am »
Continue the "breakpoint" problem.
From the mingw user mail list, I found that post below mine

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

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: [OT] MinGW GDB 7.0 is released
« Reply #41 on: October 12, 2009, 01:41:24 am »
Yes it is not done and I'm not sure if it can be done easily...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: [OT] MinGW GDB 7.0 is released
« Reply #42 on: October 12, 2009, 08:30:39 am »
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"  :D

Also, I have successfully built the gdb.exe under TDM-GCC 4.4.1 and MSYS system. :D
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: [OT] MinGW GDB 7.0 is released
« Reply #43 on: October 12, 2009, 11:39:38 am »
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:

 :(





If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline nenin

  • Almost regular
  • **
  • Posts: 202
Re: [OT] MinGW GDB 7.0 is released
« Reply #44 on: October 12, 2009, 11:47:04 am »
You can try like this:
Code
file F:/cb_svn/src/devel/share/CodeBlocks/plugins/codecompletion.dll