CppCon 2018: Simon Brand “How C++ Debuggers Work”

CppCon.org
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/Cpp...
-
Debuggers are one of the most important tools in the belt of any developer, but they are often seen as a magic black box. This is compounded by the lack of available literature, especially when compared to other toolchain components like compilers. This talk aims to demystify debuggers by showing how the utilities you use every day actually work.
Topics which will be covered include debug information and object file formats, breakpoints, stepping, register and memory manipulation, stack unwinding, multi-threaded applications, and expression evaluation. x86 Linux platforms will be used for demonstrative purposes, but the general concepts are platform independent.
-
Simon Brand, Microsoft
C++ Developer Advocate
Simon is a C++ Developer Advocate at Microsoft. He turns into a metaprogramming fiend every full moon, when he can be found bringing compilers to their knees with template errors and debating undefined behaviour online. He co-organises the Edinburgh C++ user group and contributes to various programming standards bodies.
Outside of programming, he enjoys experimental films, homebrewing, and board games.
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com *-----*
Register Now For CppCon 2022: cppcon.org/reg...
*-----*

[@onceuponapriori]

What a great talk and quite a good sport answering so many questions in the middle of his talk!

[@CppCon]

Glad you enjoyed it!

[@barrettellisadair]

Phenomenal talk in every regard. Thanks!

[@deutschWallah]

Really good Simon Brand.

[@tetraphobie]

Nice talk!
One thing to note is that in the explanation of how functions are called by the debugger (38:25), Simon said "JIT compile to machine code".
To clarify, from my experience (and looking at the source code for GDB), what GDB does when you call a precompiled function is a bunch of trickery with the debuggee's state, like adding a dummy call stack frame and calling the memory allocation function on behalf of the debuggee.
But ultimately, it will transfer execution to the original pre-compiled function and let it do the job.
Simon mentions that LLDB does JIT compile the expressions being evaluated so I presume it would do that for the function call "shim" as well, but I don't think it would re-compile the function being called, either. (Unless it's a template function or some other special case, and you're using a modern LLDB version with experimental features enabled.)
Just wanted to clarify that detail.

[@mrlithium69]

I was trying to remember where I saw this guy last, it was this: "CppCon 2018: Brand & Nash “What Could Possibly Go Wrong?: A Tale of Expectations and Exceptions”" also a useful talk.

[@muhammadhabibjawady552]

Also : How to write well-behaved value wrappers (2018) hhh

[@LesleyLai]

One of the best talks in CppCon this year I attended.

[@AbhinavGupta-i6m]

Amazing video! Thank you so much!

[@henke37]

"So this is how stack unwinding would work if you have easy access to frame pointers." (casual ohcrap) "Sometimes you don't."

[@danielro1209]

Very enlightening👍

[@CppCon]

Glad you think so!

[@informant09]

Great talk!

[@robinbuster1323]

56:55 The annotation should read ptrace calls not petrie skulls

[@mrlithium69]

@30:50 He explains that the ptrace only reads 1 word at a time. Then he gives the alternative of "process_vm_readv" which I decided to look up and found this useful kernel doc: git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fcf634098c00dd9cd247447368495f0b79be12d1 It seems to be known as CROSS_MEMORY_ATTACH which seems to ne enabled by default? and has security implications, ie: other processes are allowed to access other processes virtual memory space; although I am not qualified enough to assess these implications. I think this process_vm_readv needs more explanation on if/how this mechanism might be abused.

[@mrlithium69]

This document from Microsoft about how Windows does the security descriptors makes a lot more sense to me, docs.microsoft.com/en-us/windows/desktop/procthread/process-security-and-access-rights . Where you have to manually assign the PROCESS_VM_READ access right with SetSecurityInfo() and it requires the SeDebugPrivelege in your user token to do so, before you are allowed to do anything with another process's memory. So I still don't know how Linux compares to this. If anyone wants to explain...

[@mrlithium69]

Interestingly, Alex Ionescu wrote about a similar but opposite vulnerability, where he is concerned about malware turning themselves into Windows Protected Processes (where PROCESS_VM_READ, among other things, is disabled), so Anti-Virus/Anti-Malware won't be able to scan the address space to detect threats. www.alex-ionescu.com/?p=34

[@AleksandrSerov-rn2cn]

Can't find slides on github by link in description

[@CppCon]

Sorry, these slides are unfortunately unavailable.

[@lpadgett23]

They might be at the QR code that pops onto the screen around minute 52?

[@fahimp3]

11:08 I got so scared! Lmfao

[@Nuclearblastdrone]

Stylówe ma nie do podrobienia