[Lldb-commits] [lldb] Support disassembling RISC-V proprietary instructions (PR #145793)

[David Spickett via lldb-commits]

DavidSpickett wrote:

> For RISC-V, llvm-objdump mimics gnu objdump, so this change makes the RISC-V byte encodings match both.

Great, that's standard enough.

> That's one thing I'm trying to avoid - we don't want a filter app for objdump and another for the debugger. That's why I changed how the bytes are displayed, and changed "can't disassemble" from blank to "<unknown>", which matches llvm-objdump.

Yeah that makes sense, the glue between the tool and the filter may change a bit but a portable filter you can take between tools and toolchains is nice.

Which reminds me I didn't ask about the alternatives. I can think of a few, with their own positives and negatives:
* Adding a shared object to llvm-mc at runtime with new instructions.
  *  It "just works" (once you learn C++ and Tablegen)
  * Could load support for multiple extensions
  * You can use a prebuilt version of lldb/llvm with it
  * Except you can't because the C++ API may have changed, so you need one plugin per major version
  * I think I've heard this idea before and changing the backend structures at runtime was considered high difficulty.
* Build an llvm that supports the instructions
  * See above basically
  * Maybe you already have done this to get llvm to generate code
  * Need to build it yourself
  * Can't compose extensions
  * Need to use tools from that build, can't use GDB if you like GDB or whatever, has to be the ones in that build
* Write your own custom command that parses the original disassembler output format is, but given that it currently prints `<invalid>`, such a script would have to be magic.

Looking at it that way, I think another way to describe this proposal is:
Printing <invalid> is zero use to anyone, let's print the encoding at least, and if we're going to do that, do it in a way that can be easily parsed and read.

And that I definitely agree with.
 
Then you can multiply those pros and cons a bunch if you are a vendor, either too public or private customers. You have the effort of telling them no you have to use `<this path>/tool` not `<this other path>/tool`  (we used to have a switcher that would look at command line options and do this for us, making one for lldb would be a lot more annoying).

But now I'm making your argument for you I think. You get the idea.

The only real "gotcha" question I can come up with is, wouldn't a user who is interested in custom instructions already have access to a compiler that produces them and that compiler is likely to be llvm, so is lldb from that llvm not within reach already?

Educate me on that, I don't know how folks approach developing these extensions. Maybe code generation is the last thing they do, after they know it's worth pursuing. So you've got a lot of hand written assembler and `.inst <encoding>` going on.

> I think that's a good idea. Do you know how to add something to release notes? I've never done it upstream.

LLDB's release notes live in a section of LLVM's - https://github.com/llvm/llvm-project/blob/main/llvm/docs/ReleaseNotes.md#changes-to-lldb.

https://github.com/llvm/llvm-project/pull/145793