adrian-prantl wrote: > > adding an option to the dissemble CommandObject is the right solution. > > Personally I think I would prefer an option to the CommandObject. Do you > > think this is feasible, or are there more many points through which the > > disassembly is reachable, making an option infeasible? > > After looking more closely into one of the failing test cases, > TestFrameDisassemble.py, I noticed that its entry point for disassembly is > through `SBFrame::Disassemble()`, which bypasses the CLI entirely and doesn’t > go through `CommandObjectDisassemble`.
There are multiple options: 1. keep the original behavior and call the internal API from SBFrame::Disassemble with the flag to turn off the annotations 2. (optional) add an SBFrame::Disassemble(class DisassembleOptions) overload > Since this means command-line options like `--rich` wouldn’t apply in this > context, would it be okay if I start by introducing a new setting (e.g., > `target.enable-rich-disassembly`) to gate the annotation output globally? I think I would prefer implementing option (1) and worry about exposing the new behavior through the API later. I would like to avoid global or target-specific settings if possible, because they can introduce unwanted side effects. (Imagine an IDE that depends on the traditional disassemble format, and a user that turns on the setting in their lldbinit file). > Once that’s in place and CI is passing, I can follow up with a separate > change to add the `--rich` option to `CommandObjectDisassemble`, which would > override the setting for CLI use cases and give users more fine-grained > control. > > Does that sound reasonable? https://github.com/llvm/llvm-project/pull/147460 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
