Turn off instruction flow control annotations by default (#84607)

[jasonmolenda]

Walter Erquinigo added optional instruction annotations for x86 instructions in 2022 for the thread trace dump instruction command, and code to DisassemblerLLVMC to add annotations for instructions that change flow control, v. https://reviews.llvm.org/D128477

This was added as an option to disassemble, and the trace dump command enables it by default, but several other instruction dumpers were changed to display them by default as well. These are only implemented for Intel instructions, so our disassembly on other targets ends up looking like

(lldb) x/5i 0x1000086e4
0x1000086e4: 0xa9be6ffc   unknown     stp    x28, x27, [sp, #-0x20]!
0x1000086e8: 0xa9017bfd   unknown     stp    x29, x30, [sp, #0x10]
0x1000086ec: 0x910043fd   unknown     add    x29, sp, #0x10
0x1000086f0: 0xd11843ff   unknown     sub    sp, sp, #0x610
0x1000086f4: 0x910c63e8   unknown     add    x8, sp, #0x318

instead of disassemble's output style of

lldb`main:
lldb[0x1000086e4] <+0>:  stp    x28, x27, [sp, #-0x20]!
lldb[0x1000086e8] <+4>:  stp    x29, x30, [sp, #0x10]
lldb[0x1000086ec] <+8>:  add    x29, sp, #0x10
lldb[0x1000086f0] <+12>: sub    sp, sp, #0x610
lldb[0x1000086f4] <+16>: add    x8, sp, #0x318

Adding symbolic annotations for assembly instructions is something I'm interested in too, because we may have users investigating a crash or apparent-incorrect behavior who must debug optimized assembly and they may not be familiar with the ISA they're using, so short of flipping through a many-thousand-page PDF to understand each instruction, they're lost. They don't write assembly or work at that level, but to understand a bug, they have to understand what the instructions are actually doing.

But the annotations that exist today don't move us forward much on that front - I'd argue that the flow control instructions on Intel are not hard to understand from their names, but that might just be my personal bias. Much trickier instructions exist in any event.

Displaying this information by default for all targets when we only have one class of instructions on one target is not a good default.

Also, in 2011 when Greg implemented the memory read -f i (aka x/i) command

commit 5009f9d5010a7e34ae15f962dac8505ea11a8716
Author: Greg Clayton <[email protected]>
Date:   Thu Oct 27 17:55:14 2011 +0000
[...]
    eFormatInstruction will print out disassembly with bytes and it will use the
    current target's architecture. The format character for this is "i" (which
    used to be being used for the integer format, but the integer format also has
    "d", so we gave the "i" format to disassembly), the long format is
    "instruction".

he had DumpDataExtractor's DumpInstructions print the bytes of the instruction -- that's the first field we see above for the x/5i after the address -- and this is only useful for people who are debugging the disassembler itself, I would argue. I don't want this displayed by default either.

tl;dr this patch removes both fields from memory read -f -i and I think this is the right call today. While I'm really interested in instruction annotation, I don't think x/i is the right place to have it enabled by default unless it's really compelling on at least some of our major targets.

(cherry picked from commit bdbad0d)

[jasonmolenda]

@swift-ci test

[jasonmolenda]

@swift-ci test linux

[jasonmolenda]

@swift-ci test linux

[jasonmolenda]

@swift-ci test macos

[jasonmolenda]

@swift-ci test windows