[PATCH] D69847: DWARFDebugLoc(v4): Add an incremental parsing function

[Sourabh Singh Tomar via Phabricator via llvm-commits]

SouraVX added a comment.

In D69847#1753190 <https://reviews.llvm.org/D69847#1753190>, @labath wrote:

> I'm sorry, but I'm confused. Are you saying that the `.debug_loc.dwo` (i.e. non-standardized dwarf4 fission) location lists should be terminated with a classical `.debug_loc` double-zero entry ? That doesn't seem right -- the .debug_loc.dwo lists are in reality very different from `.debug_loc` (they use DW_LLE_*** constants and everything), and are really more similar to `.debug_loclists(.dwo)` than .debug_loc (though there are some subtle differences). It also doesn't seem to be what gcc is doing now -- this is a typical location list I get from gcc-9 -gsplit-dwarf (comments added by me):


Thanks for sharing, this I'm also sceptical here, as to what approach we should follow. You're comments seems reasonable here, But If you just try dumping this{GCC, compiled binary} -- again using llvm-dwarfdump you'll notice lots of `DW_LLE_end_of_list`. I'm not pointing you're wrong -- it's just the dump that the end user will see -- will not make sense{atleast confuses me} to him.

>           .section        .debug_loc.dwo,"e", at progbits
>   .Ldebug_loc0:
>   .LVUS0: # gcc "view" stuff -- ignore that
>           .uleb128 .LVU2
>           .uleb128 0
>   .LLST0: # DW_AT_location points here
>           .byte   0x3                  # DW_LLE_startx_length
>           .uleb128 0x1                 # index
>           .long   .LFE0-.LVL0          # length
>           .value  0x5                  # expression length
>           .byte   0x75
>           .sleb128 0
>           .byte   0x31
>           .byte   0x24
>           .byte   0x9f
>           .byte   0                # DW_LLE_end_of_list
>   .LVUS1: # next "view" starts here
> 
> 
> In practice, changing the `.byte 0` to two word-sized zeroes probably won't change anything, as the first byte of that will terminate the location list anyway. However, I don't think that's the right thing to do, and I think llvm-dwarfdump is right to display a bunch of end_of_list entries for something like that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69847