CodeLite IDE

Hi Eran,

do you think it's possible to select which C++ exceptions / signals should trigger a break to debugger? right now it's all-or-nothing for all CL instances.

I just waded through tons of GDB and libstdc++ docs but there are so many caveats it seems a nightmare. I saw "GDB catchpoints" with signal regexes/lists but they're apparently gcc 4.8+ dependent, there's "catch catch" and "catch throw", but sometimes the line where the exception is thrown doesn't have symbols, there are "personality" functions and lower-level hacking that taps directly into the C runtime. Do you know of a magic solution?

I'm trying to implement signal handlers via ASIO but I see some are being blocked in CodeLiteApp:OnInit() and anyway ASIO has other drastic requirements like moving a lot of network logic to async handlers (http://think-async.com/Asio/asio-1.5.1/ ... l_set.html). It's admittedly an extreme case; just being able to separate the type of exceptions used by client C++11 code from lower-level errors would a huge step forward. Personally I wouldn't mind using a CL-specific header in debug builds if it'd make it easier to implement.

Easy question for dessert: when the GDB program counter jumps backwards is that because "reverse debugging" kicks in? (http://www.gnu.org/software/gdb/news/reversible.html? I haven't come across it since I learned about
yet.

thx & cheers!

-- p

petah wrote:do you think it's possible to select which C++ exceptions / signals should trigger a break to debugger?

Atm, codelite uses "catch throw" (look at debuggergdb.cpp DoInitializeGdb() method). I never used anything else... (probably its because I never needed it before)

petah wrote:I'm trying to implement signal handlers via ASIO but I see some are being blocked in CodeLiteApp:OnInit()

Thats strange, since the debuggee process is not a direct child of CodeLite, but rather a child of gdb...

petah wrote:when the GDB program counter jumps backwards is that because "reverse debugging"

No (at least not that I am aware of). CodeLite uses the -exec-jump command to a specific location.

See here
http://sourceware.org/gdb/onlinedocs/gd ... ution.html

Eran

eranif wrote:

petah wrote:do you think it's possible to select which C++ exceptions / signals should trigger a break to debugger?

Atm, codelite uses "catch throw" (look at debuggergdb.cpp DoInitializeGdb() method). I never used anything else... (probably its because I never needed it before)

I didn't know this API, thx for pointing out. The are other limitations, this is the most succint one http://www.qnx.com/developers/docs/qnxc ... tions.html (despite the long url), and I assume it applies to GDB in general, whatever API is used. There's more here http://stackoverflow.com/questions/1631 ... b#16324068 detailing how different components make interception difficult.

eranif wrote:

petah wrote:I'm trying to implement signal handlers via ASIO but I see some are being blocked in CodeLiteApp:OnInit()

Thats strange, since the debuggee process is not a direct child of CodeLite, but rather a child of gdb...

Hmm, I didn't check the process hierarchy yet. I can catch a SIGHUP in my code when it's launched from outside CL, otherwise my app acts as if it hit a breakpoint but CL's call stack tab stays blank and doesn't get updated until I click on another tab and back. It's possible the problem is not the signal filtering itself but WaitForDebugger() waiting for a 2ndary thread to terminate; I use a C++11 async() call; it may lock-up on the future<> used for thread synchronization. If I try to step-debug in my main thread code after that point I hit a SIGSEGV in libc6 that I cannot intercept.

eranif wrote:

petah wrote:when the GDB program counter jumps backwards is that because "reverse debugging"

No (at least not that I am aware of). CodeLite uses the -exec-jump command to a specific location.

See here
http://sourceware.org/gdb/onlinedocs/gd ... ution.html

Ok. It usually happens when stepping out of a function; gdb makes "pitstops" further up in the code (in the same function) in places like the beginning for-loops though there's no actual breakpoint. I thought gdb was stepping through unwinding code for class dtors until I found out about that "reverse" feature. I'll try to isolate the behavior next time I see it, it's actually more funny than a nuisance.

thx & cheers,

-- p

petah wrote:gdb makes "pitstops" further up in the code (in the same function) in places like the beginning for-loops though there's no actual breakpoint.

I thought it does that too... (i.e. visiting the dtors )

BTW:
I know that you are interested in the LLDB debugger progress. Atm, I am working on small demo standalone app that uses my new set of classes for LLDB
Atm, it is capable of:

- Set breakpoints (name, file:line)
- Run
- Stop
- Continue
- Step into function
- Step out of a function
- Provide backtrace and current location

You can check out the sources and the build instructions here:
https://github.com/eranif/lldb-demo

Eran

eranif wrote:

petah wrote:gdb makes "pitstops" further up in the code (in the same function) in places like the beginning for-loops though there's no actual breakpoint.

I thought it does that too... (i.e. visiting the dtors )

Could it be -exec-stepi/nexti ? or a string-to-long conversion gone wrong. I think it usually happened after something went wrong in my code but can't really remember; seing the program counter dance around made it hard to focus

eranif wrote:BTW:
I know that you are interested in the LLDB debugger progress.

I was... I am... but I swear it was strictly out of curiousity and not related to my recent troubles - though one doesn't preclude the other.

eranif wrote:Atm, I am working on small demo standalone app that uses my new set of classes for LLDB
Atm, it is capable of:

- Set breakpoints (name, file:line)
- Run
- Stop
- Continue
- Step into function
- Step out of a function
- Provide backtrace and current location

You can check out the sources and the build instructions here:
https://github.com/eranif/lldb-demo

That's awesome! The code is so tiny & clean compared to gdb's \\\\\\/\\\\\\^\\\\ text API I assume your builds are libstdc++ based, not libc++. Once you have locals/watch resolution it should be a usable alpha...

thx again & cheers!

-- p

Eran[/quote]

Hi Petah!

First of all, let me thank you from the bottom of my heart !

You must be asking yourself "Hmm, why?"

Well, your comment about codelite swallowing signals just popped in my head and ended a 3 hours of a very long debug session!
It turns out, that while working on the lldb debugger plugin, I was using a standalone application and the future looked pink... however, once I moved the code into a plugin and started working on it within codelite - everything fell apart...
The main reason was CodeLite replacing the default SIGCHLD signal handler which broke lldb functionality...

To fix this, I added 2 new functions (available to plugins):
So when lldb plugin starts a debug session, it will call "CodeLiteRestoreSigChild()" and once the debug session has ended, it will call "CodeLiteBlockSigChild()"
(the later is needed since this is where codelite calls waitpid to avoid zombies )

Eran

A happy coincidence because... I now think the bug I see is really in ASIO itself

cheers,

-- p