tedwoodward wrote:

> For that matter, given that you're already requiring the use of a python 
> command `fdis`, is this something that could be formatted from the 
> SBInstructions in `fdis`? It does mean that you need to parse the arguments 
> instead of passing them to `disassemble`, get back the SBInstructionList, and 
> then format it in the same way llvm-objdump does, for postprocessing in the 
> other script. But it seems like this particular behavior could be contained 
> entirely within the `fdis` command, and not have `disassemble` supporting two 
> different output styles, its current one and llvm-objdump's.

`fdis` is an optional filter, implemented as a python command. This change does 
all of the disassembly updates in c++ code, so we'd get the benefits of better 
opcode formatting for RISC-V, and `<unknown>` for the disassembly of unknown 
instructions, instead of a blank.


> Is the no-0x prefix a requirement for the augmentation tool? Or will it eat 
> that and ignore it. To be honest, I don't think we should print the prefix 
> for any of the targets - it's only helpful for people doing copy and paste 
> into some tool. I've seen other tools which display the bytes of assembly in 
> a function and I can't think of any cases where I've seen one include the 
> prefix like this. It is a clear signal that these are the bytes in _big 
> endian_ order, not memory order on an LE target.

I don't know if crustfilt requires no 0x, or if it will work with 0x. It's open 
source, and really an example, so it could be changed easily. The idea (as 
explained to me) is vendors would write their own filter program, and could use 
crustfilt as a guide.
I don't think we need 0x as a prefix; llvm-objdump doesn't do it for x86, 
risc-v or hexagon.



> Should we have an eType1632Tuples (just throwing a name out there) which will 
> format the bytes in the UInt16/UInt32 combined format shown in this PR? Could 
> print "xxxx", "xxxxyyyy", "xxxxyyyy zzzz", "xxxxxyyyy zzzzaaaa" for 
> 16/32/48/64.

We could do that. I didn't want to change the Opcode::Type from eTypeBytes in 
case it was used for something besides disassembly.

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

Reply via email to