Should DW_OP_Wasm_location's "index" field be an int32 so it can be easily relocatable?

[aardappel]

DW_OP_Wasm_location currently has a type and index field that are both LEBs. For use with type TI_GLOBAL_START the index needs to be relocatable.

Doing LEB relocations in DWARF seems messy, as we need expanded LEBs that then (maybe) get re-compressed by a tool like Binaryen, if at all. int32 relocations are more common, simpler, and would better fit DWARF.

Why are we doing this at all? The first use case is having the Frame Base refer to __stack_pointer in case the function doesn't have an explicit Frame Base Local set. This is not super useful since it typically means the function has no shadow stack usage, but there may be other reasons to refer to globals from DWARF, so it be good to get this right?

For context: WebAssemblyFrameLowering::getDwarfFrameBase: https://github.com/llvm/llvm-project/blob/e8d67ada2df35ca6c70dbbe8185b0edbb18c1150/llvm/lib/Target/WebAssembly/WebAssemblyFrameLowering.cpp#L271-L274 Called from DwarfCompileUnit::updateSubprogramScopeDIE: https://github.com/llvm/llvm-project/blob/e8d67ada2df35ca6c70dbbe8185b0edbb18c1150/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp#L423-L432 Calls into DwarfExpression::addWasmLocation: https://github.com/llvm/llvm-project/blob/e8d67ada2df35ca6c70dbbe8185b0edbb18c1150/llvm/lib/CodeGen/AsmPrinter/DwarfExpression.cpp#L585-L591

This functionality originally introduced in https://reviews.llvm.org/D52634 https://reviews.llvm.org/D44184

Or maybe we should do this entirely differently? How does this affect unwinding by the debugger?

cc: @dschuff @sbc100 @kripken @yurydelendik @sunfishcode