c[ode]clap»Blog

alpha 0.5.5

spx
codeclap 0.5.5 is here.

It is no 0.5.0, but something better ;).

In addition to the established Linux build there are now also working builds for macOS and Windows. The macOS build is correctly signed to be used as a debugger and should work out of the box without any self-signing chaos.
The Windows build is the most recent and had a few teething problems but should work ok now. But it definitely received the least amount of testing.

Also codeclap is now available on https://codeclap.itch.io/codeclap for a very moderate price which will provide access to all 0.x and 1.x builds.
For now the Patreon is no more and everyone who has contributed in the past has received a free download key.

The interface is still not the most intuitive but a switchable help overlay may help the confusion a little bit.

Here is a little overview of the current state in video form which is also linked on the itch.io page:
https://www.youtube.com/watch?v=iLkYimo2RI4

For the sake of completion here is the CHANGELOG with the most important changes from the last build.
There is one known issue that could potentially cause a freeze of the debugger but I hope that a workaround for that one is working for now until I have fixed it the correct way which unfortunately is platform specific yet again and will take a bit.

[00.05.05]
* Fixed a crash because of a bigger than expected memory copy when incorrectly using a wrong value returned by the OS memory read

[00.05.04]
* [pdb/DWARF] Fixed mapping functions that start directly at a mapped region beginning into the virtual address space

[00.05.03]
* Fixed a regression that would change the expression focus instead of the autocomplete selection when a autocompletion overlay is active
* Display "Tab" key correctly in shortcut string representations
* Fixed some sites calling the wrong longjmp implementation and faulting
* Workaround: Do not try to change the execution state of a thread that is currently in a syscall

[00.05.02]
* Added a few small improvements to the cursor tracking behavior which should ensure that the point of execution is always visible
* Warn and allow for different actions when trying to set conflicting keybindings
* Fixed a regressions that would incorrectly show an old copy of the rbp, rsp or rip register when used in expressions
* Added a small builtin help overlay dubbed "training wheels" mode which shows some help labels directly within the UI
* [Linux/macOS] Fixed a regression that would cause the pause and continue all threads buttons to fail
* [Windows] Fixed starting the debugger directly using the command line and passing a binary and optionally a function to run to
* [Windows] Fixed a potential issue that would stall the debugger trying to execution expressions in the debuggee
* [macOS] Fixed a bug that would not correctly exit the application when run from command line with a parameter to directly start the debugger
* [macOS] Force mouse tracking on render when it has not been activated before

[00.05.01]
* [Windows] Fixed an issue that would incorrectly use the working directory for configuration files instead
of the program directory

[00.05.00]
* Changed the way inlined functions are displayed (panel instead of a window)
* Implemented more DWARF ops to support debug information from optimized code
* Fixed reading DW_FORM_block for DW_TAG_const_value
* Fixed a few inconsistencies when scrolling or moving the cursor in the debugger view
* [Windows] Fixed referencing the wrong memory anchor after multiple starts
* [Windows] Implemented additional pdb specs to handle optimized code
* [Windows] Some changes for handling S_LOCAL, S_REGREL32, S_BPREL32 and S_REGISTER in optimized builds
* [Windows/macOS] Fixes dropping binaries onto the configuration window
* pdb/DWARF Fixed iterating in/over functions without children
* Fixed allocating an excessive amount of memory when converting source file encodings
* Improved stepping over source lines in optimized code
* [Linux/macOS] Changed simple debugging loop to event queue
* [macOS] Fixed possible hang when debuggee output waits for processing
* Added a set of test cases for the core debugging functionality
* Initialize expression results with 0 to avoid unwanted breakpoint stops when the expression execution fails
* Added tests to ensure basic debugger functionality is working
* [DWARF] Fixed a failure to correctly resolve a function if an address from a nearby compilation unit has been active before
* In the top panel highlight the currently active/selected thread
* Fixed a bug that startup configurations would not be persisted correctly
* [Windows] Fixed a bug that would skip calls that have to be executed on the main debugging thread
* [Windows] Changed the way processes are terminated to avoid locking windows in an infinite thread spawning loop
* Fixed a bug for pop instructions when generating the stacktrace
* [DWARF] Fixed a rare bug that would point source line references to wrong instruction addresses
* [DWARF] Fixed an off-by-one that would wrongly map addresses at the compile unit boundary end into the wrong compile unit
* Changed some const-sized memory allocations to dynamic allocations
* [macOS] Suspend all threads when an unexpected signal occurred
* Explicitly show information when an exception has occurred
Looks like a lot of new features have been added!

Having a issue with the Linux build, likely user error. If I start a configuration without a "Break at Function:" configured I can see the assembly code but not the source even when switching between views. If I enter a function name and start the configuration the program starts and never actually hits the break point. Any thoughts?
spx
joe513
Looks like a lot of new features have been added!

Having a issue with the Linux build, likely user error. If I start a configuration without a "Break at Function:" configured I can see the assembly code but not the source even when switching between views. If I enter a function name and start the configuration the program starts and never actually hits the break point. Any thoughts?

The assembly you are seeing is where the OS enters the executable, it is unlikely that you have the source for that region on your machine. However when a "main" or "WinMain" function is found the debugger will offer you to run to that function, so if that popup is missing it probably has not found such a function in the debug information (or did no find the debug information at all).

You can check this by using the "jump to any" dialog (by default Ctrl+Shift+P) and check if one of your functions are there.

Out of curiosity to maybe find the problem relatively quick, what distribution are you using and what compiler switches have you used to compile your source (maybe also the compiler version)?
I tried the jump to anything and the window just closes and goes back to the same assembly.

Description: Manjaro Linux
Release: 18.0.0-rc

gcc (GCC) 8.2.1 20180831


I made a small test program to eliminate other issues. Compiling with:
gcc -g main.c -o out

For functions to break at I have tried "main" and "addInt".

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
#include <stdio.h>

int addInt(int a, int b)
{
    int result;
    result = a + b;
    return result;
}

int main()
{
    int x = addInt(5, 5);
    printf("Value is %i\n", x);
    return 0;
}


As far as codeclap configuration, I am just dropping the generated "out" program from above into the main window and using the default configurations.




spx
I can reproduce the problem on Manjaro ;).

It seems that codeclap fails completely to find any valid debug information.
In the jump dialog you normally would see entries to select from based on the input in the text field.

Could be that GCC 8 is the culprit here. I haven't used it myself because it has a bug that makes it impossible to compile the codeclap source and I only know of a fix for this in GCC 9. But could also be something completely unrelated.

Will look into this on Monday.
spx
Edited by spx on
Also good thing is that I was able to reproduce the problem casey had on stream and have an idea where this issue comes from.

//
Another quick update for the Manjaro issue. GCC8 is not at fault (and 8.2.1 also has the bug fixed that prevented me from upgrading). The problem is that codeclap uses 2 criteria to find mapped files in memory, the region has to be executable and start at the beginning of the file. On Manjaro the region mapped from the beginning of the file is not executable and the search logic codeclap applies falls apart.
spx
@joe513 I'd encourage you to give it another shot. 0.5.8 should work a lot better. I've also made sure that all tests are successful on Manjaro.
spx
@joe513 I'd encourage you to give it another shot. 0.5.8 should work a lot better. I've also made sure that all tests are successful on Manjaro.


Working as expected now. The autocomplete and goto anything are great! Will test more this afternoon.