User forums > General (but related to Code::Blocks)

[OT] unofficial MinGW GDB gdb with python released

<< < (8/35) > >>

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:

--- Quote from: ollydbg on October 11, 2009, 03:40:42 am ---
You can set breakpoints in both exe and dll, but for gdb.exe 7.0, only breakpoints in exe file can be reached.


--- End quote ---

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

ollydbg:

--- Quote from: nanyu on October 11, 2009, 06:04:26 am ---
--- Quote from: ollydbg on October 11, 2009, 03:40:42 am ---
You can set breakpoints in both exe and dll, but for gdb.exe 7.0, only breakpoints in exe file can be reached.


--- End quote ---

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

--- End quote ---

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:

--- Quote from: killerbot on October 08, 2009, 01:50:58 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"

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

With another string it is ok.

--- End quote ---

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

--- End code ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page