Consider adding DW_TAG_base_type to Swift's basic types for Chrome DWARF extension

[kateinoigakukun]

Debugging

Debugging Wasm modules is challenging because Wasm does not expose ways to introspect and control the execution of the Wasm instance, so a debugger cannot be built on top of Wasm itself. Therefore, special support from the Wasm execution engine is necessary for debugging.
The current state of debugging tools in the Wasm ecosystem is not as mature as other platforms but there are two main directions:

1. LLDB debugger with Wasm runtime supporting GDB Remote Serial Protocol [1]
2. Wasm runtime with a built-in debugger [2]
   The first approach provides an almost equivalent experience to existing debugging workflows on other platforms. It can utilize LLDB's Swift support, remote metadata inspection and serialized Swift module information. However, since Wasm is a Harvard architecture and has no way to allocate executable memory space at runtime, implementing expression evaluation with JIT in user space is challenging. In other words, gdb stub in Wasm engines need tricky implementations or need to extend the GDB Remote Serial Protocol.
   The second approach embeds the debugger within the Wasm engine. In scenarios where the Wasm engine is embedded as a guest language in another host language engine (e.g. within a Web Browser), this approach allows seamless debugging experiences with the host language by integrating with the host debugger. For example, in cases where JavaScript and Wasm call frames are interleaved, the debugger works well in both contexts without switching tools. Debugging tools like Chrome DevTools can use DWARF information embedded in Wasm file to provide debugging support. However, supporting Swift-specific metadata information and JIT-based expression evaluation will require integrating LLDB's Swift plugin with these debuggers in some way.
   Given that both approaches can utilize DWARF information, the Swift toolchain should generate as much DWARF information as possible for statically known things. Also, making Swift type information DWARF-friendly is desirable because the current debug information generated by the Swift compiler assumes that debuggers can understand certain Swift primitives (e.g. Swift.Int is currently represented as a DW_TAG_structure_type node without any member but ideally such types should be represented as DW_TAG_base_type nodes with DW_AT_encoding attribute or provide a debug summary string by LLDB Summary Strings)
   [1]: [lldb] Implement WebAssembly debugging llvm/llvm-project#77949
   [2]: https://github.com/ChromeDevTools/devtools-frontend/blob/main/extensions/cxx_debugging