[llvm-bugs] [Bug 46804] New: llvm-dwarfdump cannot handle .debug_ranges/.debug_loc empty relocated range in ET_REL object

[via llvm-bugs]

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

            Bug ID: 46804
           Summary: llvm-dwarfdump cannot handle .debug_ranges/.debug_loc
                    empty relocated range in ET_REL object
           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

See http://lists.llvm.org/pipermail/llvm-dev/2020-July/143575.html for full
context.

A .debug_ranges/.debug_loc sequence ends with an entry containing 0 for the two
addresses. In a fully-linked object, llvm-dwarfdump handles this fine. However,
in an ET_REL file, there might be relocations patching an apparent 0, 0 entry.
The parsing code does resolve relocations before determining if an address is
zero. However, if the relocations happen to be section-relative (or
symbol-relative, where the symbol is at a section start), the resultant address
will be the relocation addend, which could be 0 in both cases.

Simple example:

.section .foo,"a", at progbits
nop

.section .debug_ranges,"", at progbits:
.quad foo
.quad foo
.quad 0, 0 # actual terminator

This is a particular problem in .debug_loc, where the entry might have some
data afterwards, so a premature termination will cause parsing to completely
fail.

The solution is to not treat an address patched by a relocation as 0, for the
purpose of termination.

-- 
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/d42bee88/attachment.html>