Problem debugging in header only functions.

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

[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

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

[eranif]

What is the default behavior?

As it is today - always keep current behavior as default

Can you report the issue or tell me where to go?

I would, if I knew

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

Code: Select all

b main

Using the MI interface:

Code: Select all

-break-insert main

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

[RJP Computing]

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.

[eranif]

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

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