Cannot convert memory offset values for instructions with local references

[OmarDarwish]

It appears that sometimes you cannot convert offset values to other number representations if the current instruction you are trying to convert has a reference. See the attached video at https://twitter.com/ohmarzing/status/1229487069434535937?s=20

As per that thread, @ArrrCaptain suspected that these are actually locals, which Ghidra does not allow you to convert since they are internally represented as labels. (I'm probably incorrect in Ghidra jargon here, so please bare with me.).

When I removed the reference attached to these locations, I was then able to convert the offsets. If this is working as intended, then please consider allowing conversion of offsets tied to locals like what is allowed for other similar locations.

[ghidra1]

Unable to view video within our environment. Could you please post sample instruction with local markup and with convert markup. Are you trying to perform the convert action or simply see the conversions tooltip? Local stack variable markup replaces a scalar offset thus there is no visible scalar to be seen for convert to work (i.e., scalar equate).

[ckimyt]

He's trying to perform the convert action, which is enabled, on the scalar offset (unsure why the scalar offset is showing up instead of local stack label...OP did you erase locals? Rename them as hex strings?). Why would the convert action be enabled when the local stack markup will always replace the scalar offset? Seems like that is misleading to be able to select and apply the conversion but then not see evidence of it.

[OmarDarwish]

I was trying to convert the offsets listed for 0x8048561, which was a reference variable that was automatically identified by auto analysis.

The Convert menu item appears, but does not have any affect.

[OmarDarwish]

OP did you erase locals? Rename them as hex strings?

Nope. Although as per the linked Twitter thread, if I delete the stack reference at that location, the offset is in fact shown as a signed decimal value.

[Franck78]

Hello, I think my issue is about the same as this one. Unable to 'easily' convert an immediate value to a label / address. Here is code , Z80. The HALT instruction is followed by the code to execute . Address 07D1 is loaded into HL.

                         **************************************************************
                         *                          FUNCTION                          *
                         **************************************************************
                         undefined FUN_ram_0d78()
         undefined         A:1            <RETURN>
                         FUN_ram_0d78                                    XREF[21]:    FUN_ram_07be:07c0(c), 

        ram:0d78 e5              PUSH       HL
        ram:0d79 21 7f 0d        LD         HL,0xd7f
        ram:0d7c 76              HALT
        ram:0d7d e1              POP        HL
        ram:0d7e c9              RET
        ram:0d7f c5              PUSH       BC
        ram:0d80 cd 8a 0d        CALL       FUN_ram_0d8a                                     undefined FUN_ram_0d8a()
        ram:0d83 c1              POP        BC
        ram:0d84 af              XOR        A
        ram:0d85 32 00 40        LD         (Watchdog),A                                     = ??
        ram:0d88 ed 45           RETN

It could also be a recognized Z80 construction (HL=offset; HALT)

Using GHIDRA 11.0.1

[ghidra1]

When marking-up an operand for redering, only one replacement/change is made. In your case the canary memory reference prevails over a scalar equate. It does seem like this could be improved upon. In general, all markup tries to target a relavent scalar except when there is no apparant way to derive the reference offset from a scalar value in which case the => notation is used to place the markup.