[LLVMbugs] [Bug 14655] New: Bug in accelerator table hash code

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Wed Dec 19 13:34:41 PST 2012


http://llvm.org/bugs/show_bug.cgi?id=14655

             Bug #: 14655
           Summary: Bug in accelerator table hash code
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: echristo at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


It looks like the documentation for dwarf accelerator tables here:

http://llvm.org/docs/SourceLevelDebugging.html#name-accelerator-tables

doesn't match the implementation here:

lib/CodeGen/AsmPrinter/DwarfAccelTable.cpp

I believe this results in a bug in the implementation.

In particular, when there is a hash collision (different strings, same hash),
the implementation produces a hashes array of size greater than
header.hashes_count.

ComputeBucketCount counts the unique hash values, but it modifies no data
structure except Header.hashes_count and Header.bucket_count.

When FinalizeTable builds the buckets, it does not consider if a particular
hash value is already in the bucket. (It does uniquify the dies in
HashDataContent, but it does so by die_offset so that doesn't apply here.)

EmitHashes iterates through the buckets and emits hash values, again without
regards to duplicate hash values.

Likewise with EmitOffsets.

Therefore, Header.hashes_count will be too small, and anything relying on that
value will terminate early. I suspect there isn't anything that does, but
anyway.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the llvm-bugs mailing list