Add variable from script about bit-slicer

[zorgiepoo]

It's not possible. Currently you have to do everything from a script, figure out another way to dynamically locate the address (via editing the address's formula), do something in between like copy & paste from logs or some hack using the process' memory as your own storage.

Consider this a feature request that may depend on #16... Perhaps I'd envision allowing an existing variable to be an output rather than arbitrarily allowing adding variables to the table.

[wesselvdv]

I have built something that can facilitate this exact use case. I’ve added a second optional parameter to the vm.allocate function that allows you to define a label for the memory address of the allocated region. (e.g. vm.allocate(8, 'importantPointer')

I’ve also added a new function (label) for DDMathParser which you can use as following with the above label in the address field of a variable: [label('importantPointer')] + 0x5.

I’ll open a PR for this but I am sure the impl. will require some polishing. It’s not that big of an addition. (In terms of LoC).

[zorgiepoo]

Interesting approach. I don't think vm.allocate is appropriate for that but maybe a setLabel function can be added instead. That way you can label something existing too.

[zorgiepoo]

And I guess for completeness it should be possible to set a label to an address in the UI too.

[wesselvdv]

Interesting approach. I don't think vm.allocate is appropriate for that but maybe a setLabel function can be added instead. That way you can label something existing too.

Yeah, I had realized this as well. I figured that debug.setLabel and debug.removeLabel is the best to add instead.

Regarding the UI approach. I believe labels should be associated with a document then. The easiest approach is added a optional label property on ZGVariable, and adding a specific ZGLabelManager to manage all label associations? Unless you’re referring to the MemoryViewer and/or Debugger?

[zorgiepoo]

Yeah, I had realized this as well. I figured that debug.setLabel and debug.removeLabel is the best to add instead.

Either just debug.setLabel (and have None set no label or remove existing label) or addLabel and removeLabel. Former may make more sense.

Regarding the UI approach. I believe labels should be associated with a document then.

I think this is a fine approach. I don't think the ZGVariable's should have a label property then, since labels would be for the document, not variable. The variable address formula would just reference the label. Maybe setting labels in the UI could be done later.

[wesselvdv]

Setting labels in the UI is a bit more work than I initially thought. I think the best approach is to have a dedicated spot where one can view all labels that exists for a document. I am not sure what the best way to display them is. (Maybe something like what's done in the debugger view with the registers/trace)

I do believe that the best approach would be to create a ZGLabel container class for a ZGVariable, because I see two main use cases for labels:

1. Assign a static address to a label. (From a script or maybe manually through some UI interaction)
2. Assign the result of an address formula (from a variable with type ZGPointer) to a label.

Now, both cases can be easily supported when a ZGLabel has a addressFormula field and associated semantics similar to ZGVariable. You could even go as far as saying that a ZGLabel is in fact a ZGVariable with an immutable size (4 for 32bit and 8 for 64bit) and type (pointer), and that it has an additional field name which allows it to be referenced in ZGVariable addressFormula field(s) using the aforementioned label() mechanic.

I'll try to play around with that concept a bit, but I won't do anything with displaying all existing labels for a document yet. As I have no idea what the best approach is for that. Maybe a SplitView in the Search Document with both a Variables and Labels TableView? Where the Labels view is hidden by default but can be toggled or something?

I also see a possible issue with cyclic references of labels, but I am not sure if this is a real issue. I do know how to detect these, but that requires a lot more code and subsequent UI/UX to guide the user. So I'd prefer to not add it yet.