CDbg » Forums » A few of my collected comments
azmr
Andrew Reece
51 posts / 1 project

Maker of things

#16927 A few of my collected comments
7 months, 1 week ago Edited by Andrew Reece on Dec. 7, 2018, 8:02 p.m.

I made a couple of notes while using `cdbg` so that I wouldn't bombard you with lots of small things.
I haven't added anything to the file for a while, so I thought it's probably a good time to put things up here while they're still relevant.

Initial Feedback

I've ditched MSVC for this. It's such a nice experience:
  • starts up and steps quickly
  • nice UI presentation - colours and layout
  • image debug is useful


Bugs
  • when opening from command line with -t argument and cdbg's full path specified, e.g.:
    1
    "E:\Program Files\cdbg_build_0.0.0.7\cdbg64.exe" -t test.exe
    

    there seems to be a parsing issue at the space in Program Files. When I hit F1 in the newly opened window, the executable path comes up as:
    1
    E:\Documents\Coding\C\build\Files\cdbg_build_0.0.0.7\cdbg64.exe"  -t test.exe
    

    This was fixed by adding cdbg64 to my PATH and calling cdbg64 myfile.exe
  • a cmd window pops up for printf output. If I close this instead of hitting Shift+F5, cdbg crashes. I think the same occurs with normal windows. It (sometimes?) pops up with a message box saying:
    1
    2
    3
    4
    5
    6
    Panic!
    ======
    
    Invalid code path
    File: "w:\\dbg\\code\\win64_tracer.c"
    Line Number: 1391
    
  • finding the next search value (ctrl+s) doesn't seem to do anything
    • EDIT: worked out why this is - keep tapping / rather than Vim-style enter then "find next"
  • long lines of C-style comments confuse the syntax highlighter, seemingly something to do with there being no space before the end of the comment:
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
/* block 1 *****************************************************/
{
    int this_is_highlighted_as_comment = 1;
}
/* end block 1 */

/* block 2 *************************************************** */
{
    int this_is_not_highlighted_as_comment = 0;
}
/* end block 2 */
  • When hovering over variables to find out their value, the 'active/hoverable area' is offset to the left. It seems to be offset by 1 character per level of indentation. Here is a very realistic example:
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
// [] indicates hot region (pun partially intended)
int spicy         = 12;
int mild          = 4;
int extra_spice   = 9;
int sausage_spice = [mild];

while([extra_spice]--)
    +[+sausage_spic]e;
    if(sausage_spice >= spicy) {
        printf("HOT: sausage has spice level of %d\n"[, sausage_spi]ce);
    }
}

EDIT: this seems to be due to the indent size defaulting to 5, but the hot zone assuming an indent of 4


Requests

These are all things that I can see being useful to my personal workflow:
  • When looking at a stack level lower than the current stack top, you don't seem to be able to easily inspect the values at that level of the stack.
  • When arrays are expanded in the inspector, then you change to a scope where the array is invalid, then return to the array-valid scope, the array is no longer expanded. How difficult would it be to have it flagged to reopen when valid again?
  • Ditto, but for when arrays change length.
  • allow ptrs to be broken into 2 dimensions (currently you can give length after comma)
  • For an array of structs, filter array output to show only some members of the struct at each position of the array
  • Would it be possible to have macro expansion in the inspector? My most common use cases are either expanding to constants, or getting the length of a stretchy_buffer-like array. It's not the end of the world typing struct_x.array, ((ahd_arr*)struct_x.array-1)->len, but struct_x.array, arr_len(struct_x.array) would be a bit easier.
  • Break All - most useful when stuck in an infinite loop and unsure where.
  • Step out of scope
  • Allow us to break on the end bracket of a scope - to see the result of a final calculation/loop etc
  • image updating when the data behind it changes
  • improved breakpoint tracking when other lines are added before
  • when outputting PDBs from clang, MSVC seems to be able to debug the files as if compiled with cl, but cdbg doesn't seem to be able to (unless I'm missing some other flags) - it loads the symbols but can't find an entry point. It also doesn't stop if I use fbreak WinMain