[llvm-bugs] [Bug 44258] New: Don't truncate the DW_TAG value when parsing abbrevs

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Dec 9 08:06:29 PST 2019


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

            Bug ID: 44258
           Summary: Don't truncate the DW_TAG value when parsing abbrevs
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: DebugInfo
          Assignee: unassignedbugs at nondot.org
          Reporter: jh7370.2008 at my.bristol.ac.uk
                CC: jdevlieghere at apple.com, keith.walker at arm.com,
                    llvm-bugs at lists.llvm.org,
                    paul_robinson at playstation.sony.com

LLVM's DWARF.h restricts the DW_TAG/AT/FORM enums to uint16_t size. It is true
that all known values fit in this field, including any user-defined ones in the
designated ranges. However, in the DWARF spec, these values are recorded in
.debug_abbrev declarations as ULEB128, which has no technical upper-limit.

This becomes a problem when parsing .debug_abbrev sections with unknown tag
values that are greater than 16-bits, e.g. "0x10000". In
DWARFAbbreviationDeclaration::extract, we static cast the result of the ULEB
parsing of the tag value to a dwarf::Tag, resulting in the value being
truncated. This can either end up in a value of 0 for the aforementioned value
of 0x10000, which is interpreted as an end of abbrevs block, or another
arbitrary value. The former results in an incorrect parsing of the rest of the
section, whilst the latter will result in potentially incorrect interpretations
of the tag (e.g. 0x10001 causes llvm-dwarfdump to print the tag as
"DW_TAG_unknown_0x4000" instead of the more correct "DW_TAG_unknown_0x10001").

-- 
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/20191209/8d9f5182/attachment.html>


More information about the llvm-bugs mailing list