I noticed that llvm-symbolizer gives wrong results sometimes, this was due to incorrect sizes of some symbols. The reason for that was an incorrectly sorted array in computeSymbolSizes. The comparison function used subtraction of unsigned types, which is incorrect. Let's change this to return explicit -1 or 1.
Details
- Reviewers
dberris kcc dvyukov • rafael aprantl - Commits
- rGcf8d1fc3d815: [asan] Re-enable the use-after-scope-types.cc test on Darwin, now that r287028…
rGa3ccf3ddbd12: Fix llvm-symbolizer to correctly sort a symbol array and calculate symbol sizes
rCRT287029: [asan] Re-enable the use-after-scope-types.cc test on Darwin, now that r287028…
rL287029: [asan] Re-enable the use-after-scope-types.cc test on Darwin, now that r287028…
rL287028: Fix llvm-symbolizer to correctly sort a symbol array and calculate symbol sizes
Diff Detail
Event Timeline
testcase?
Unfortunately, it's hard to come up with a reasonable testcase because the issue is hard to reproduce on small inputs (because the sorting usually works and only edge cases sort incorrectly). One of compiler-rt tests fail due to this, however. So with this patch, I can enable the test again. Is that enough?
Is it possible to manufacture a test in unittests/Object/ ?
I spend some time trying to, and I'm giving up on writing a subclass of ObjectFile that I could give to computeSymbolSizes. The best I could come up with was to pull SymEntry and compareAddress into a header file and just test that array_pod_sort sorts correctly. Will that do?
lib/Object/SymbolSize.cpp | ||
---|---|---|
18–19 | It would be good to document what the ordering guarantees are at the interface level for this function -- for instance, is this a strict weak ordering on (section id, address)? |
It would be good to document what the ordering guarantees are at the interface level for this function -- for instance, is this a strict weak ordering on (section id, address)?