DWARF, Traits, Debug Info Changes, and Procedural Macros

It prevents processes using `ptrace` syscall. If a process wants to use `ptrace` it has to be code signed. The certificate that signs it has to be trusted on your machine. See [Apple developer documentation for System Integrity Protection]. We may need to sign up with Apple and get the keys to do this signing. Tom has looked into if Mozilla cannot do this because it is at the maximum number of keys it is allowed to sign. Tom does not know if Mozilla could get more keys. Alternatively, Tom suggests that maybe a Rust legal entity is needed to get the keys via Apple. This problem is not technical in nature. If we had such a key we could sign GDB as well and ship that. ### DWARF and Traits Rust traits are not emitted into DWARF at all. The impact of this is calling a method `x.method()` does not work as is. The reason being that method is implemented by a trait, as opposed to a type. That information is not present so finding trait methods is missing. DWARF has a notion of interface types (possibly added for Java). Tom's idea was to use this interface type as traits. DWARF only deals with concrete names, not the reference types. So, a given implementation of a trait for a type would be one of these interfaces (`DW_tag_interface` type). Also, the type for which it is implemented would describe all the interfaces this type implements. This requires a DWARF extension. Issue on Github: [https://github.com/rust-lang/rust/issues/33014] ## Typical process for a Debug Info change (LLVM) LLVM has Debug Info (DI) builders. This is the primary thing that Rust calls into. This is why we need to change LLVM first because that is emitted first and not DWARF directly. This is a kind of metadata that you construct and hand-off to LLVM. For the Rustc/LLVM hand-off some LLVM DI builder methods are called to construct representation of a type. The steps of this process are as follows: 1. LLVM needs changing. LLVM does not emit Interface types at all, so this needs to be implemented in the LLVM first. Get sign off on LLVM maintainers that this is a good idea. 2. Change the DWARF extension. 3. Update the debuggers. Update DWARF readers, expression evaluators. 4. Update Rust compiler. Change it to emit this new information. ### Procedural macro stepping A deeply profound question is that how do you actually debug a procedural macro? What is the location you emit for a macro expansion? Consider some of the following cases - * You can emit location of the invocation of the macro. * You can emit the location of the definition of the macro. * You can emit locations of the content of the macro. RFC: [https://github.com/rust-lang/rfcs/pull/2117] Focus is to let macros decide what to do. This can be achieved by having some kind of attribute that lets the macro tell the compiler where the line marker should be. This affects where you set the breakpoints and what happens when you step it. ## Source file checksums in debug info Both DWARF and CodeView (PDB) support embedding a cryptographic hash of each source file that

This section covers the challenge of representing Rust traits in DWARF, proposing the use of interface types and outlining the process for making debug info changes in LLVM and the Rust compiler. It also addresses the problem of debugging procedural macros, discussing where to emit location information for macro expansions. Finally, it mentions the support for embedding source file checksums in debug info using DWARF and CodeView (PDB).