[wazari972]

I'm personally a big fan of vanilla GDB, at least for plain C debugging. Disclaimer: I spent >5years on a PhD work searching how to extend GDB for parallel and embedded programming.

    I can't easily see the surrounding code

I have Emacs on the side window, so I use GDB to see the immediately surrounding code, and Emacs to see the rest of the function. I do exactly the same for Python debbuging with PDB

    I have to manually request information rather than just glancing at the display

I just print the variables I want to see, there are not so many of them I'm actually interested in while debugging

    I have to remember syntax rather than just clicking on things
    ...and in this case, it took me a few tries to correctly deref this pointer to an fixed-size array

those are the tradeoff between flexibility and ease. You can access any memory locations, and cast it in many different ways, examine the assembly to precisely understand the next steps, examine the bits to precisely understand the storage (only endianness issues remained tricky to follow)

[FpUser]

>"You can access any memory locations, and cast it in many different ways, examine the assembly to precisely understand the next steps"

This is not the exclusive domain of GDB. I have all those features in various Windows based IDEs all working in friendly manner.

[jamii]

> those are the tradeoff between flexibility and ease

It isn't a required tradeoff. Most of the gdb frontends I tried display the local variables at all time, but also allow writing arbitrary gdb expressions if I want to. Having both is clearly better.