CODEWITHSUNDEEP
pythonxcodelldb
Jasongiss
Jasongiss

Reputation: 278

LLDB Python scripting create variable

I am using LLDB Python scripting support to add custom Variable Formatting for a complex C++ class type in XCode.

This is working well for simple situations, but I have hit a wall when I need to call a method which uses a pass-by-reference parameter, which it populates with results. This would require me to create a variable to pass here, but I can't find a way to do this?

I have tried using the target's CreateValueFromData method, as below, but this doesn't seem to work.

import lldb

def MyClass(valobj, internal_dict):

  class2_type = valobj.target.FindFirstType('class2')
  process = valobj.process
  class2Data = [0]
  data = lldb.SBData.CreateDataFromUInt32Array(process.GetByteOrder(), process.GetAddressByteSize(), class2Data)


  valobj.target.CreateValueFromData("testClass2", data, class2_type)
  valobj.EvaluateExpression("getType(testClass2)")
  class2Val = valobj.frame.FindVariable("testClass2")
  if not class2Val.error.success:
    return class2Val.error.description

  return class2Val.GetValueAsUnsigned()

Is there some way to be able to achieve what I'm trying to do?

Upvotes: 0

Views: 293

Answers (1)

Jim Ingham
Jim Ingham

Reputation: 27110

SBValue names are just labels for the SBValue, they aren't guaranteed to exist as symbols in the target. For instance if the value you are formatting is an ivar of some other object, it's name will be the ivar name... And lldb does not inject new SBValue's names into the symbol table - that would end up causing lots of name collisions. So they don't exist in the namespace the expression evaluator queries when looking up names.

If the variable you are formatting is a pointer, you can get the pointer value and cons up an expression that casts the pointer value to the appropriate type for your getType function, and pass that to your function. If the value is not a pointer, you can still use SBValue.AddressOf to get the memory location of the value. If the value exists only in lldb (AddressOf will return an invalid address) then you would have to push it to the target with SBProcess.AllocateMemory/WriteMemory, but that should only happen if you have another data formatter that makes these objects out of whole cloth for its own purposes.

It's better not to call functions in formatters if you can help it. But if you really must call a function in your data formatter, you should to do that judiciously.

They can cause performance problems (if you have an array of 100 elements of this type, your formatter will require 100 function calls in the target to render the array... That's 200 context switches between your process and the debugger, plus a bunch of memory reads and writes) for every step operation.

Also, since you can't ensure that the data in your value is correct (it might represent a variable that has not been initialized yet, or already deallocated) you either need to have your function handle bad data, or at least be prepared for the expression to crash. lldb can clean up the stack and suppress the exception from crashes, but it can't undo any side-effects the expression might have had before crashing.

For instance, if the function you called took some lock before crashing that it was expecting to release on the way out, your formatter will damage the state of the program. So you have to be careful what you call...

And by default, EvaluateExpression will allow all threads to run so that expressions don't deadlock against a lock held by another thread. You probably don't want that to happen, since that means looking at the locals of one thread will "change" the state of another thread. So you really should only call functions you are sure don't take locks. And use the version of EvaluateExpression that takes an SBExpressionOption, in which you set the SBExpressionOptions.StopOthers to True, and SetTryAllThreads to False.

Upvotes: 1

Related Questions