c[ode]clap»Forums
Lachlan
22 posts
Issues/Requests

Hi, I'm using Codeclap 0.9.7.1 on x86_64 linux (Ubuntu 20.04)

Issues:

  1. Running an X11 application in codeclap and closing it with the window's 'X' button, codeclap will not close the process correctly, e.g. If I continually open and close an application this way and pgrep <application> the list of PIDs grows. If I close the application with 'Stop/F12' this 'persistence' doesn't happen.
  2. If I load a shared object with dlopen codeclap does not pick up its debug information and does not stop at any function breakpoints inside the shared object.

Requests:

  1. When I stop an application and then start it again I would like codeclap to remember where my cursor was previously. I find it annoying having the cursor start at main() all the time and having to scroll to the part of the code I was just at.
  2. Implement a memory window like in Visual Studio
  3. Implement gdb server support (useful for qemu and embedded projects)

Thanks

spx
148 posts / 1 project
Issues/Requests

Hi,

regarding your issues:

  1. I wasn't yet able to reproduce this. At least not with a "minimal X11 example". I may still be able to find something when looking deeper into differences how the application exits in both ways; this could be something like a timing issue when the child process doesn't exit fast enough. Is there anything in your environment that differs from the default 20.04 installation (desktop environment, ..)?

  2. This should work but only (and that may be the problem here) if the debugger breaks at some point roughly when/after reaching main and before the dlopen happens. I can see how this can be unexpected and annoying at times and will look into fixing this.

requests:

  1. Good point. I will have to think a bit about the behavior, for example if ignoring breakpoints until the cursor is hit could be a good idea but I wouldn't yet know how to handle if the cursor isn't hit at all which then would be really confusing. So to start with I may limit this to something like "restart and break at the current position". Not sure if it is best to do this for all threads currently in "stopped" state or only the one that was last debugged.

  2. I tend to avoid windows that have one very specific narrow functionality but having something like a "single expression" panel could be a good idea. When used with a ",mem" expression this is pretty much exactly what you described while being capable of doing more for example be an assembly panel when used with ",asm" etc.

  3. After adding remote debugging support this would be at least a bit easier. However from what I gathered from the gdbserver documentation it is rather unlikely this will happen anytime soon.

Best regards

Lachlan
22 posts
Issues/Requests
Replying to spx (#25471)

I'm using xfce4 as my desktop environment so this differs from the default GNOME (GNOME has an annoying bug handling multiple keyboards).

If I set a breakpoint in the shared object it does not get stopped at.