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

[OT] unofficial MinGW GDB gdb with python released

<< < (9/35) > >>

ollydbg:
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


--- End quote ---

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:

--- Quote from: mariocup on October 08, 2009, 01:31:50 pm ---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.


--- End quote ---

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

ollydbg:
I just find more bugs of GDB.

Follow the steps

--- Quote from: ollydbg on October 12, 2009, 01:25:30 am ---
 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'


--- End quote ---

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:

--- End code ---

 :(

nenin:
You can try like this:

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

--- End code ---

Navigation

[0] Message Index

[#] Next page

[*] Previous page