[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