alpha 0.5.8 for Linux

spx  —  1 month ago [Edited 0 minutes later]
0.5.8 is available for Linux which fixes a few important problems.
  • codeclap wasn't able to handle executable memory regions that would not start at the beginning of the file, this would render the debugger unable to locate debugging information on certain Linux distributions.
  • shortly before release the technology to execute code injected into the debuggee got put into a more central place. This worked fine in limited tests (especially in automated test) and also based on the platform. However especially on Windows this blew up pretty quickly. This build changes this behavior to not hijack the control flow of the debuggee (which was especially problematic near syscalls) and instead uses its own thread in the remote process.


So this build should work a lot better during actual usage. Unfortunately this has to be ported to every platform and I still consider the Windows and macOS build "kind of broken" at this point. However this should be fixed very soon.

Download it at: https://codeclap.itch.io/codeclap

Changelog for 00.05.08
[Linux] Changed the stopping bahavior to be executed on the debugger thread
[Linux] Inject a debugger owned thread into the debuggee to execute code instead of hijacking debuggee threads (this will fix issues around syscalls and such)
[Linux] Improved reading mapped regions in memory to consider regions that don't start with an executable region
Fixed a segfault causes by trying to persist ondemand startups (sessions started from the terminal without any internal ID)
[DWARF] Fixed a bug that would relocate memory and invalidate a pointer when processing line sections
Fixed a bug that would print assembly lines at the end of a file twice
#16753
Simon Anciaux  —  1 month ago
Could a 32bit linux version happen in the future ?
#16754
spx  —  1 month ago
mrmixer
Could a 32bit linux version happen in the future ?

Difficult to say for short/mid term. I guess what makes codeclap different from a very simple debugger is that I use quite a few technologies that are a bit "reverse-engineery" (which is no accident, there is a lot of cool things one can do with that); For example most of the expressions are generated as assembly instructions, injected into the process and then executed all "at once" in one go. Limiting that to x64 makes things simpler for now, there are only 2 calling conventions (sysv and windows), one set of syscalls for Linux etc.

So it is definitely possible but I would have to collect all the places where I currently require x64 specification and provide different implementations for that. And I think at least on the desktop 32bit is more and more fading away? or is that wrong, maybe for smaller more limited devices? It's the same for arm/arm64, i'd love to support that, but it will require time and resources. Also maybe loadable modules for different architectures.
#16762
Simon Anciaux  —  1 month ago
spx
And I think at least on the desktop 32bit is more and more fading away?

That's probably true. I was asking because my linux machine is 32bit. So don't make it for me, I'd prefer you spend your time on the most useful case.
#16764
joe513  —  1 month ago [Edited 11 minutes later]
Is it possible to start from the command line by passing in the program name without using the project configuration?

//edit
I answered my own question, it does work. I was not passing in the complete path for the program name. It also looks like I can pass in the function name to break at. Are there any other arguments that can be passed in? Perhaps filename/line number.
#16767
spx  —  1 month ago
joe513
I answered my own question, it does work. I was not passing in the complete path for the program name. It also looks like I can pass in the function name to break at. Are there any other arguments that can be passed in? Perhaps filename/line number.

I think you got basically all just by trial and error. You can get a very brief overview when passing "-h" on the command line (on Linux it is actually a tiny bug that codeclap opens even when passing "-h"; also "-h" isn't working on Windows right now because of their decision to not allow prompt output for GUI applications).

Two remarks that come to my mind in this regard:
1. I have underestimated the importance of being able to directly launch from the command prompt and will extend that in the future.
2. --overlay still exists and I haven't touched it since my first tech demos (one of the screenshots on the project page is using overlay mode). So it may be totally broken and by all means usability is not good. I will soon integrate overlay mode into the UI and make sure that it is working equally on all platforms (macOS is the hardest to get right from what I've seen because the window apparently behaves differently when launched from an .app instead of launched directly using the executable).
#16770
joe513  —  1 month ago [Edited 0 minutes later]
spx

1. I have underestimated the importance of being able to directly launch from the command prompt and will extend that in the future.


Glad to hear this will expanded in the future. Just a couple feature request when that time comes.
1) Ability to specify the "Working directory" right now it fails to find files even in the same directory as the application
2) Break point at file_name:line_number. (if this is even possible)

Overall great work!
Log in to comment