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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
