[lldb-dev] ValueObjectChild and SetData

[Greg Clayton via lldb-dev]

> On Aug 5, 2020, at 1:50 PM, Gabor Greif via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> Hi LLDB devs,
> 
> short question. Since the method
> 
>  bool ValueObjectChild::SetData(DataExtractor &data, Status &error)
> 
> doesn't exist, what is the preferred way to update the contents of
> scalar bitfields?
> 
> Is there any code in the repo demonstrating the technique?
> 
> I am interested, because for the language I am writing a plugin for
> certain datatypes are MSBit-aligned, e.g. a Nat16 occupies the upper
> portion of the bits in a (32-bit) word.
> 
> Viewing and setting of such variables thus involves shifting bits, and
> I'd expect that ValueObjectChild (in bitfield mode) would do that for
> me.
> 
> Thanks in advance for any clues,
> 
> cheers,
> 
>    Gabor

What is the debug information format being used for these? If it is DWARF, the location expression for the variable should take care of extracting the value correctly. 

A bit more info: Each ValueObject has a "Value m_value;" member variable that contains the value of the variable. This "Value" object has many member variables:

class Value {
  Scalar m_value;
  Vector m_vector;
  CompilerType m_compiler_type;
  void *m_context;
  ValueType m_value_type;
  ContextType m_context_type;
  DataBufferHeap m_data_buffer;
};

The "m_value_type" helps us to know how to interpret the value itself which is either contained in "Scalar m_value;" or "DataBufferHeap m_data_buffer;". ValueType is one of:

  enum ValueType {
    // m_value contains...
    // ============================
    eValueTypeScalar,      // raw scalar value
    eValueTypeVector,      // byte array of m_vector.length with endianness of
                           // m_vector.byte_order
    eValueTypeFileAddress, // file address value
    eValueTypeLoadAddress, // load address value
    eValueTypeHostAddress  // host address value (for memory in the process that
                           // is using liblldb)
  };

eValueTypeScalar means that the value itself is actually in "Scalar m_value;". This is the typical way that built in types (ints, floats, chars, etc) get resolved. For bitfields, this value should already be shifted around as necessary when the location information from the debug info was parsed and used to create the value at a specific location in the code.

eValueTypeFileAddress means that "m_value" contains a "file address" which points to the location of the variable in memory. This value will need to be converted to a "load address" when we extract the value and then we will read the value from process memory each time we get the location.

eValueTypeLoadAddress means that "m_value" contains a "load address" which points to the memory address in the process where we will read the value from.

eValueTypeHostAddress means that "m_value" contains an address in the LLDB process itself. This is typically used for variables that are constructed with complex location expressions that might say "2 bytes of my value are at XXX, 4 bytes of my value are in this register and 2 bytes are constant". So when we evaluate the location expression, it will hand us a buffer that contains the variable value.

So your case seems like a standard bitfield case where the debug info should be adequately describing the bitfield and everything should just work. Are there any reasons why you think this might not be happening?

Greg

> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev