From 10aa22c4839dca2d83211f72204bff553acbbd53 Mon Sep 17 00:00:00 2001 From: Andy McFadden Date: Fri, 27 Jun 2025 13:07:38 -0700 Subject: [PATCH] Tweak Edit Operand Target Label If an instruction or data operand has been given an explicit symbol, the user will expect to edit the label at that address rather than the numeric address. Same for project symbols. If we detect that a symbol has been set, edit that directly. If the symbol doesn't exist, or isn't a user label or project symbol (e.g. platform symbol or address region pre-label), we open the full operand editor instead. --- SourceGen/CodeAnalysis.cs | 2 +- SourceGen/MainController.cs | 42 +++++++++++++++++++++++++++++++++++++ 2 files changed, 43 insertions(+), 1 deletion(-) diff --git a/SourceGen/CodeAnalysis.cs b/SourceGen/CodeAnalysis.cs index 99c29a3..85b5ae1 100644 --- a/SourceGen/CodeAnalysis.cs +++ b/SourceGen/CodeAnalysis.cs @@ -1082,7 +1082,7 @@ namespace SourceGen { } /// - /// Sets the format of an instruction operand. + /// Sets the format of an instruction operand. Invoked from extension script. /// /// Offset of opcode. /// Format sub-type. diff --git a/SourceGen/MainController.cs b/SourceGen/MainController.cs index abac086..eacdddd 100644 --- a/SourceGen/MainController.cs +++ b/SourceGen/MainController.cs @@ -2545,6 +2545,48 @@ namespace SourceGen { internalLabelOffset.ToString("x6") + " extSym=" + externalSym + " extAddr=" + externalAddr + " isLV=" + isLV); + // Check to see if a symbol has been explicitly set. If so, we want to edit the + // label at the address for that symbol, or the project symbol entry, rather than + // using the numeric value of the operand to do the determination. This feels better + // because you're editing the label shown on screen in the operand field. + if (mProject.OperandFormats.TryGetValue(selOffset, out FormatDescriptor dfd) && + dfd.FormatType == FormatDescriptor.Type.NumericLE && + dfd.FormatSubType == FormatDescriptor.SubType.Symbol) { + // Symbol formats are weak references, so we need to look the label up in the + // symbol table to ensure that it exists. Non-local label references will have + // the uniquification string appended. + string label = dfd.SymbolRef.Label; + bool didEdit = false; + if (mProject.SymbolTable.TryGetNonVariableValue(label, out Symbol foundSym)) { + if (foundSym.SymbolSource == Symbol.Source.User) { + // Edit the label at the target address. + int labelOffset = mProject.FindLabelOffsetByName(label); + if (labelOffset >= 0) { + DoEditLabel(labelOffset); + didEdit = true; + } else { + Debug.Assert(false, "Can't edit symbol " + foundSym); + } + } else if (foundSym.SymbolSource == Symbol.Source.Project) { + // Edit the symbol we found. + Debug.Assert(foundSym is DefSymbol); + DoEditProjectSymbol(CodeListColumn.Label, (DefSymbol)foundSym); + didEdit = true; + } else { + // Could be a platform symbol, or we managed to get something odd in here. + // Whatever the case, fall through to the "uneditable" case. + } + } + if (!didEdit) { + // If we can't edit it for whatever reason, just open the appropriate Edit + // Operand dialog, so they can fix the symbol name. Seems more appropriate + // than posting an error dialog or quietly doing nothing. + Debug.WriteLine("Unable to cleverly edit '" + label + "', doing EO"); + EditOperand(); + } + return; + } + // Operand targets can be internal or external, and can be in an LVT. Internal // address user labels have the highest priority, LVTs are next, then external // project/platform symbols.