clayborg added a comment. In D78801#2007795 <https://reviews.llvm.org/D78801#2007795>, @labath wrote:
> In D78801#2007083 <https://reviews.llvm.org/D78801#2007083>, @clayborg wrote: > > > It would be fine to ask the lldb_private::Process class to evaluate any > > unknown DWARF expression opcodes like DW_OP_WASM_location and return the > > result. > > > While that idea has occurred to me too, I am not convinced it is a good one: > > - it replaces one odd dependency with another one. Why should a Process need > to know how to evaluate a DWARF expression? Or even that DWARF exists for > that matter? This seems totally unrelated to what other Process functions are > doing currently... But it is what people do in reality. DW_OP_low_user and DW_OP_high_user are ranges that are made available to people to customize their DWARF opcodes. If you don't handle it, you are hosed and can't show a variable location. And to make things worse, two different compilers could both use the same value in that range. So they made DWARF expressions customizable with no real attempt to make them function for different architectures. that is unless you standardize it and make a real opcode that gets accepted into DWARF. The kind of DWARF location opcode that is being used here could easily be generalized into a DW_OP_get_stack_variable with a bunch of args, but at some point you have to talk to someone that is in communication with the runtime of the thing you are debugging to get the answer. So I do believe asking the process for this is not out of scope. > - I am not sure it even completely removes wasm knowledge from e.g. > DWARFExpression -- the class would presumably still need to know how to parse > this opcode. It is true and this is another hole in the "people can extend DWARF easily" scenario. We need to know what opcode arguments are and that would need to be hard coded for now. But it wouldn't have to rely on anything except virtual function on the generic lldb_private::Process/Thread APIs. In this case as soon as we get an unknown opcode we would need to pass the DataExtractor and the offset into it so the process could extract the arguments. Not clean, but better than making DWARFExpression depend on process plug-ins IMHO. > - the interface could get very complicated if we wanted to implement typed > stacks present in DWARF5 -- presumably the API would need to return the type > of the result, in addition to its value. DWARF5 just further clarifies what each value on the opcode stack is (file address, load address, the value itself, etc). Right now DWARF expression just infer what a value is based on the opcodes. So I don't see a huge problem here as anything we do will need to work with DWARF5. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D78801/new/ https://reviews.llvm.org/D78801 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
