[Lldb-commits] [PATCH] D85376: Fix how ValueObjectChild handles bit-fields stored in a Scalar in UpdateValue()

Shafik Yaghmour via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Tue Aug 11 14:49:59 PDT 2020

shafik added a comment.

In D85376#2209638 <https://reviews.llvm.org/D85376#2209638>, @labath wrote:

> This manifested itself for variables in registers because those end up being described as `eValueTypeScalar`, is that so?
> If that's the case, then I think this would also manifest for variables described via `DW_OP_constu 0xdead, DW_OP_stack_value`. And if *that* is true, then this could be tested a lot simpler by having a global variable described by DW_OP_stack_value and "target variable"-ing it -- no makefiles, no python, just a simple .s file. And it would run on all platforms, not just darwin.
> `test/Shell/SymbolFile/DWARF/DW_OP_piece-struct.s` tests a very similar thing in precisely this way. I suspect you could just take that test as a template and replace the struct definition with one that contains bitfieds.

This sounds like a great approach, I have unfortunately been struggling to get a test case that works. It looks like I am hitting another bug, I am not surprised b/c using slight variations on this code I have found other three other bugs with how we deal with `DW_OP_piece`, `DW_OP_bit_piece` and I think `DW_AT_const_value` respectively.

I have been working w/ this:

  #include <stdio.h>
  typedef union
    unsigned raw;
      unsigned a : 8;
      unsigned b : 8;
      unsigned c : 6;
      unsigned d : 2;
      unsigned e : 6;
      unsigned f : 2;
    } ; 
  } U;
  static U ug= (U)(unsigned)0x0;
  void f(U u) {
    printf( "%d\n", u.raw);
  int main() {
    ug.raw = 0x64A40101;
    printf( "%d\n", ug.raw);

and compiling as using `clang -O1 -gdwarf-4` but we obtain bad values:

  (lldb) target variable ug
  (U) ug = {
    raw = 3395301392
     = (a = 16, b = 48, c = 32, d = 1, e = 10, f = 3)

I tried generating assembly and manually adjusting the debug info but I was not able to get very far there.

FYI this was the DWARF expression it was generating:

  DW_AT_location	(DW_OP_addr 0x100002010, DW_OP_deref_size 0x1, DW_OP_constu 0x64a40101, DW_OP_mul, DW_OP_lit0, DW_OP_plus, DW_OP_stack_value)

If you can come up w/ a way to generate a test that produces correct values I am happy to use it!



More information about the lldb-commits mailing list