location lists from dwarf5

I added during past weekend support for var location lists from DWARF5 (located in separate section .debug_loclists) in my dwarfdump. As usually lots of bugs were found

First - they presents only for functions but not for methods. Probably this is real bug and can have serious impact when debugging

Second - generated expressions is not optimal. Lets see example:

locx 53e
4FB5DF - 4FB5F4: DW_OP_piece 0x8, DW_OP_reg0 RAX, DW_OP_piece 0x8, DW_OP_breg0 RAX+0, DW_OP_lit3, DW_OP_lit8, DW_OP_mul, DW_OP_plus, DW_OP_stack_value, DW_OP_piece 0x8
4FB5F4 - 4FB60F: DW_OP_piece 0x8, DW_OP_reg2 RCX, DW_OP_piece 0x8, DW_OP_breg0 RAX+0, DW_OP_lit3, DW_OP_lit8, DW_OP_mul, DW_OP_plus, DW_OP_stack_value, DW_OP_piece 0x8


As you can see this expressions are the same but for adjacent addresses ranges. Why not use single expression for range 4FB5DF - 4FB60F?

Update: I have made patch to estimate amount of identical adjacent location lists. C++ extractor from codeql has total 149850 lists and 116 redudant or 0.077%

DW_OP_mul just pops from stack couple of values and put back result of their multiplication (see evaluation logic in method execute_stack_op), so this sub-expression can be rewritten as just DW_OP_lit24

Also it`s curious to check what other compilers support subj:

gcc

Yes, with options -g -gdwarf-5 -fvar-tracking

golang

No - they even don`t support DWARF5 at all

openwatcom v2

No - judging by the funny comments

WHEN YOU FIGURE OUT WHAT THIS FILE DOES, PLEASE DESCRIBE IT HERE!

clang on windows

it's really wonderful - vs2010 falls on target check-clang:

llvm 3.3 - wtf ?

was built under xp 64bit with visual studio 2010
And I got:
30>  Testing Time: 106.52s
30>  ********************
30>  Failing Tests (32):
30>      LLVM :: CodeGen/ARM/lsr-scale-addr-mode.ll
30>      LLVM :: CodeGen/X86/rodata-relocs.ll
30>      LLVM :: Linker/2003-08-24-InheritPtrSize.ll
30>      LLVM :: Linker/2008-03-05-AliasReference2.ll
30>      LLVM :: Linker/2008-07-06-AliasFnDecl2.ll
30>      LLVM :: Linker/2008-07-06-AliasWeakDest2.ll
30>      LLVM :: Linker/2009-09-03-mdnode2.ll
30>      LLVM :: Linker/2011-08-04-DebugLoc2.ll
30>      LLVM :: Linker/2011-08-04-Metadata2.ll
30>      LLVM :: Linker/2011-08-18-unique-class-type2.ll
30>      LLVM :: Linker/2011-08-18-unique-debug-type2.ll
30>      LLVM :: Linker/2011-08-22-ResolveAlias2.ll
30>      LLVM :: Linker/DbgDeclare2.ll
30>      LLVM :: Linker/available_externally_b.ll
30>      LLVM :: Linker/linkmdnode2.ll
30>      LLVM :: Linker/linknamedmdnode2.ll
30>      LLVM :: Linker/metadata-b.ll
30>      LLVM :: Linker/module-flags-1-b.ll
30>      LLVM :: Linker/module-flags-2-b.ll
30>      LLVM :: Linker/module-flags-3-b.ll
30>      LLVM :: Linker/module-flags-4-b.ll
30>      LLVM :: Linker/module-flags-5-b.ll
30>      LLVM :: Linker/module-flags-6-b.ll
30>      LLVM :: Linker/module-flags-7-b.ll
30>      LLVM :: Linker/module-flags-8-b.ll
30>      LLVM :: Linker/partial-type-refinement-link.ll
30>      LLVM :: Linker/testlink2.ll
30>      LLVM :: Linker/unnamed-addr1-b.ll
30>      LLVM :: Linker/visibility2.ll
30>      LLVM :: MC/MachO/gen-dwarf-producer.s
30>      LLVM :: Transforms/ArgumentPromotion/byval-2.ll
30>      LLVM :: Transforms/LoopSimplify/indirectbr.ll
30>
30>    Expected Passes    : 8274
30>    Expected Failures  : 52
30>    Unsupported Tests  : 264
30>    Unexpected Failures: 32
Is it "normal" ?

clang and msbuild integration

chapter 12 of "Inside the Microsoft Build Engine" describes how you can add mingw toolchain to msbuild (visual studio 2010 and newer versions)
So I was very glad to see this patch. But it seems that it does not contains nothing usefull and just don't works !
I wonder if there are some way to integrate clang with msbuild. I missed something ?