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

[Shafik Yaghmour via Phabricator via lldb-commits]

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;
    struct 
    {
      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);
    return;
  }
  
  int main() {
    ug.raw = 0x64A40101;
  
    f(ug);
    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!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85376/new/

https://reviews.llvm.org/D85376