[PATCH] D55261: [llvm-dwarfdump] - Simplify the test case.

[George Rimar via Phabricator via llvm-commits]

grimar marked an inline comment as done.
grimar added inline comments.


================
Comment at: test/tools/llvm-dwarfdump/X86/no_debug_addr.s:5-6
+## When .debug_addr is absent for some reason, check we do not print a bogus section name.
+## We had a bug that could be a reason of that when
+## DW_RLE_startx_length/DW_RLE_base_addressx/DW_RLE_offset_pair tags were used.
 
----------------
dblaikie wrote:
> Not sure I understand this comment - but I think I get where you're going with it, might just be some grammar improvement to make it more clear?
> 
> Oh, actually, here's a thought - did this bug pop-up when using rnglists in .dwo files? They certainly won't have a debug_addr & would then be a fully realistic scenario rather than one where a section of debug info would have to be dropped to demonstrate the failure?
> 
> So maybe a comment like this:
> 
>   ## Ensure bogus empty section names are not printed when dumping rnglists that reference debug_addr when it is not present (such as in .dwo files).
> 
> Yep, looks like it does, so here's a really short example I worked up:
> 
>         .section        .debug_info.dwo,"e", at progbits
>         .long   .Ldebug_info_dwo_end1-.Ldebug_info_dwo_start1   # Length of Unit
>   .Ldebug_info_dwo_start1:
>         .short  5                       # DWARF version number
>         .byte   5                       # DWARF Unit Type
>         .byte   8                       # Address Size (in bytes)
>         .long   0                       # Offset Into Abbrev. Section
>         .quad   -6809755978868859807
>         .byte   1                       # Abbrev [1] 0x14:0x32 DW_TAG_compile_unit
>         .byte   0                       # DW_AT_ranges
>   .Ldebug_info_dwo_end1:
>         .section        .debug_abbrev.dwo,"e", at progbits
>         .byte   1                       # Abbreviation Code
>         .byte   17                      # DW_TAG_compile_unit
>         .byte   0                       # DW_CHILDREN_no
>         .byte   85                      # DW_AT_ranges
>         .byte   35                      # DW_FORM_rnglistx
>         .byte   0                       # EOM(1)
>         .byte   0                       # EOM(2)
>         .section        .debug_rnglists.dwo,"e", at progbits
>         .long   .Ldebug_rnglist_table_end1-.Ldebug_rnglist_table_start1 # Length
>   .Ldebug_rnglist_table_start1:
>         .short  5                       # Version
>         .byte   8                       # Address size
>         .byte   0                       # Segment selector size
>         .long   1                       # Offset entry count
>   .Lrnglists_dwo_table_base0:
>         .long   .Ldebug_ranges0-.Lrnglists_dwo_table_base0
>   .Ldebug_ranges0:
>         .byte   1                       # DW_RLE_base_addressx
>         .byte   0                       #   base address index
>         .byte   4                       # DW_RLE_offset_pair
>         .byte   0                       #   starting offset
>         .byte   1                       #   ending offset
>         .byte   3                       # DW_RLE_startx_length
>         .byte   1                       #   start index
>         .byte   2                       #   length
>         .byte   0                       # DW_RLE_end_of_list
>   .Ldebug_rnglist_table_end1:
> 
> 
> 
Idea about using the .dwo is interesting, thanks! I'll check it and probably update this patch tomorrow.

> Oh, actually, here's a thought - did this bug pop-up when using rnglists in .dwo files? 

I faced this in LLD actually. Its implementation of the `llvm::DWARFObject` did not override the `getRnglistsSection`
and the effect from returning the empty section by default implementation was the same as rnglists section is absent.


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

https://reviews.llvm.org/D55261