Design of Debug Info for Carbon

[dwblaikie]

• line tables - already implemented, doesn't seem likely to need any novel features for Carbon
• function calls in debugger expression evaluation:
  • add type information for parameters
  • what if the Carbon ABI differs from the ABI the debugger understands (debuggers generally bake-in knowledge of the platform ABIs they support, Carbon intends to have a floating ABI)
    • @chandlerc suggested possibly emitting C++-interop-like thunks (for any function that would require a thunk if called from C++)
      • maybe use the mangled name of the thunk for the debug info description of the function
      • debug info could possibly describe a discontiguous address range covering both the thunk and the real function body
• type layout descriptions
  • how to describe value representations?
    • use a distinct type in debug info? (eg, create a nested type MyClass::ValueType that has the value type representation, duplicate description of the member functions, etc?) but then the debugger probably needs help figuring out how to call func(MyClass) with a MyClass::ValueType argument - maybe synthesize implicit conversion operators from MyClass to MyClass::ValueType the debugger can use and describe the function as func(MyClass::ValueType) instead - which matches the semantics of Carbon, I think (you can't get back from the value representation to the... full? representation)