[PATCH] D25253: [codeview] Translate bitpiece metadata to DEFRANGE_SUBFIELD* records

[Reid Kleckner via llvm-commits]

rnk added inline comments.


> amccarth wrote in SymbolRecord.h:813
> Is the mask correct?  Three nybbles kinda looks like a typo, and it's used on the StructOffset which is 15 bits, so I expected `0x7FFF`.  If the mask is correct, then maybe `0x0FFF` would be clearer.

It's 12 bits. You can see what's going on here:
https://github.com/Microsoft/microsoft-pdb/blob/e6b1dec61e154b568357537792e1d17a13525d5d/include/cvinfo.h#L4262

They have a bitfield like this:

  unsigned short  spilledUdtMember : 1;   // Spilled member for s.i.
  unsigned short  padding          : 3;   // Padding for future use.
  unsigned short  offsetParent     : 12;  // Offset in parent variable.

However, I screwed up. The low bits are allocated first. I need to come up with a test case that exercises this functionality.

> rnk wrote in SymbolRecord.h:813
> It's 12 bits. You can see what's going on here:
> https://github.com/Microsoft/microsoft-pdb/blob/e6b1dec61e154b568357537792e1d17a13525d5d/include/cvinfo.h#L4262
> 
> They have a bitfield like this:
> 
>   unsigned short  spilledUdtMember : 1;   // Spilled member for s.i.
>   unsigned short  padding          : 3;   // Padding for future use.
>   unsigned short  offsetParent     : 12;  // Offset in parent variable.
> 
> However, I screwed up. The low bits are allocated first. I need to come up with a test case that exercises this functionality.

Uh, actually I screwed it up. It's 12 bits, but I got them backwards. :(

Apparently I didn't exercise this case. I need to come up with a test case that spills a piece of sliced aggregate.

> amccarth wrote in pieces.ll:2
> Is it redundant to check both the ASM and OBJ output?  Your change affects the ASM directly.  The OBJ check seems like it's covering ground that should already be handled in the llvm-readobj tests.  Am I missing something?

I'm trying to test that the assembly that we emit forms valid codeview records that llvm-readobj can understand. Basically, I'm worried that `.cv_def_range .Ltmp7 .Lfunc_end0, "C\021\030\000\000\000\000\000\000\000"` might not actually result in a well-formed record, and the object file test gives me confidence in it.

> majnemer wrote in pieces.ll:168
> What is wrong?

We aren't turning `#DEBUG_VALUE: nested:o <- [%RCX+0]` into something good. It's not really SROA / subfield related, though, since `o` is passed indirectly as a pointer in RCX.

https://reviews.llvm.org/D25253