[llvm-bugs] [Bug 46805] New: Regression in handling 0-length address range entries

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=46805

            Bug ID: 46805
           Summary: Regression in handling 0-length address range entries
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-dwarfdump
          Assignee: unassignedbugs at nondot.org
          Reporter: jh7370.2008 at my.bristol.ac.uk
                CC: llvm-bugs at lists.llvm.org

This regression was introduced in
https://reviews.llvm.org/rGed9851a0a682d1ff288ed749287fbc7682ed1514 (see
https://reviews.llvm.org/D71932 for the review).

A .debug_aranges table might contain an entry for a zero-length function or
data. This is not forbidden by the standard, and can happen in practice. In
such a case, it should not be an error. In up to at least LLVM version 9, this
worked fine, but the cited change caused an error to start occurring. Example:

PS C:\Work\TempWork> llvm-dwarfdump.exe --debug-aranges bar.elf
bar.elf:        file format elf64-x86-64

.debug_aranges contents:
error: address range table at offset 0x0 has an invalid tuple (length = 0) at
offset 0x10

A trivial asm input might look like:
foo:

.secton .debug_aranges,"", at progbits
... # Some data for the header
.quad foo
.quad 0 # 0 length
.quad 0 # The .debug_aranges terminator
.quad 0

Note that simply removing the error message is not quite the right fix - we
still want to emit an error if a terminator is detected before the claimed end
of the file, but beware a similar issue to bug 46804, where in an ET_REL file,
the address might appear to be zero, but it is relocated.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200722/2ca316f5/attachment.html>