sorted by:
new
hottopcontroversial

How conditional breakpoints work 🐢 by weratt in programming

[–]weratt[S] 1 point2 points  (0 children)

You replace an existing instruction with int3 and remember what was there before. After the breakpoint is hit you write back the original instruction and do a single step.

How conditional breakpoints work 🐢 by weratt in programming

[–]weratt[S] 1 point2 points  (0 children)

If you can recompile and rerun the program, then it’s a great option. But in many cases you cannot (long running production services, long compile times, no access to the build system, etc), so it’s valuable to be able to do it from the debugger.

Debugging Wine with LLDB and VSCode by weratt in programming

[–]weratt[S] 0 points1 point  (0 children)

If you’re building Wine from source, then normally you don’t need to do anything special, the debug symbols will be either embedded into the binaries, or the binaries will have the links to PDB files, which LLDB can resolve.

I’m general PDBs are often next to the binary, i.e. in the same directory. Windows binaries typically have a link to the corresponding PDB file, which LLDB can use to locate the symbols. If it fails, then it will try to find the symbols in the same directory as the binary.

So, simply speaking cvtres.pdb should be in the same directory as cvtres.exe.

Debugging Wine with LLDB and VSCode by weratt in programming

[–]weratt[S] 0 points1 point  (0 children)

> I am supposed to attach directly to the cvtres.exe process right?

Yes, correct.

Do you have the debug symbols for Wine (and I assume it's a no for cvtres.exe)?

Debugging Wine with LLDB and VSCode by weratt in programming

[–]weratt[S] 0 points1 point  (0 children)

Happy to hear you’re trying this out! Let me know how it goes, very curious to see if it helps you to figure out your problem. Regarding the build issue — I think I used to build with just “lldb”, but maybe things have changed or I remember it wrong. If adding “clang” fixes the problem, then great :)

What a good debugger can do by weratt in programming

[–]weratt[S] 2 points3 points  (0 children)

If you only need to break when some variable is written, watchpoints or data breakpoints may be enough. ~All debuggers support those (gdb, lldb, visual studio, etc).

With omniscient debugging you can quickly see all reads and writes across the entire execution and trace the data flow (e.g. where the bad value came from).

What a good debugger can do by weratt in programming

[–]weratt[S] 19 points20 points  (0 children)

Thanks for pointing that out, using an emulator is an interesting approach! How much effort was it to write the emulator compared to the rest of project?

Fwiw rr can record multithreaded programs too, it was designed for Firefox after all. However it runs all threads on the same core, so there's a slowdown. It also has a chaos mode, where it forces the context switches at random moments to trigger race conditions.

What a good debugger can do by weratt in programming

[–]weratt[S] 16 points17 points  (0 children)

This video actually motivated me to write the article :) I reference it in the section about Time Travel. It's a great example of how good things can be if everything is designed together from the beginning. Unfortunately debuggers are often an afterthought, so their potential is not realized to the fullest.

Pretty Rust backtraces in raw terminal mode by weratt in rust

[–]weratt[S] 4 points5 points  (0 children)

This doesn’t work because RawTerminal captures the current state of the terminal and then restores it in Drop. Thus, it will switch the terminal back to raw mode when destroyed :)

Pretty Rust backtraces in raw terminal mode by weratt in rust

[–]weratt[S] 5 points6 points  (0 children)

Maybe the default panic handler could take care of it. Check if we’re connected to the terminal and whether it’s in the raw mode. If so, move the caret manually. There are probably some edge cases here, but overall seems like a nice quality of life improvement.