Page 1 of 1
Problem debugging in header only functions.
Posted: Tue Apr 14, 2009 1:15 am
by RJP Computing
Hi.
I have worked out an example that shows there is a problem setting breakpoints in a function that has a header only implementation. Also it is important to note that CodeLite is messing up setting the breakpoints when you have the starting path to the '#include' as an additional compiler include path.
It works from the commandline (gdb.exe) and in Code::Blocks.
Here are some things I found:
- Only set a breakpoint in the file 'wxtools\wx\serialization\combobox.h'. It will not set the breakpoint.
- If you set a breakpoint in a cpp (headerbrk.cpp) that includes the header then it will set the breakpoint properly.
Please let me know if you need more details.
Re: Problem debugging in header only functions.
Posted: Tue Apr 21, 2009 7:42 pm
by eranif
Hi,
I committed a fix for this in the SVN trunk.
basically, i added a new option for the debugger to use 'short file names' (settings -> debugger settings...'), by enabling it codelite will path the full name of a file (w/o path) which seems to fix this problem.
yet, this is a gdb bug and should also be reported there (the same debugging fails from command line as well using the MI interface)
Eran
Re: Problem debugging in header only functions.
Posted: Tue Apr 21, 2009 8:17 pm
by RJP Computing
I will build it and test. What is the default behavior? To send relative paths seems better until the user has a real reason to use full paths, which break in headers.
Can you report the issue or tell me where to go?
Also how do you use the IM interface? I am not sure what that is and how to use it.
Re: Problem debugging in header only functions.
Posted: Tue Apr 21, 2009 10:05 pm
by eranif
RJP Computing wrote:What is the default behavior?
As it is today - always keep current behavior as default
RJP Computing wrote:Can you report the issue or tell me where to go?
I would, if I knew
RJP Computing wrote:Also how do you use the IM interface? I am not sure what that is and how to use it.
The MI (Machine Interface) is a differnt set of commands to pass to gdb, it is designed for application who whishes to build a UI on top of the gdb command line debugger.
For example:
CLI interface (common interface):
Using the MI interface:
The main difference is the output - which is very easy parsed, and the ability to attach a unique ID to each command I send to the debugger. when attaching a unique ID to a command, GDB will set that ID back with the reply so I application could tell which command triggered that response.
This behavior allows me to support async command like this:
Code: Select all
00000001-break-insert main
00000002-break-insert myfile.cpp:10
00000003set breakpoint pending on
I can send this bulk of commands to GDB, and read the output on different thread, or at OnIdle event, the replies will contain the ID (0000000X) attached to the request
Eran
Re: Problem debugging in header only functions.
Posted: Tue Apr 21, 2009 11:19 pm
by RJP Computing
eranif wrote:
As it is today - always keep current behavior as default
Hum. I would suggest this changes. The reason is because other IDE's can debug these with no problem. Also it seems like a smarter choice to do what works all the time. Especially if it is not time consuming.
Re: Problem debugging in header only functions.
Posted: Wed Apr 22, 2009 9:38 am
by eranif
RJP Computing wrote:Hum. I would suggest this changes
Well, I would agree with you if it was a common case, but it is not - this is the first time this bug was reported in over 2 years that codelite is out.
So I prefer keeping the current behavior over going to the new one, which might lead to other unknown bugs which were yet reported/discovered
RJP Computing wrote:The reason is because other IDE's can debug these with no problem.
Well now, so does codelite.
Beside, I am not in a competition with other IDEs
Eran