> On Aug 5, 2020, at 1:50 PM, Gabor Greif via lldb-dev
> <[email protected]> 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
> [email protected]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
