[PATCH] D97975: [libFuzzer] add attribute noinline on Fuzzer::ExecuteCallback()

Ulrich Weigand via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 11 03:18:29 PST 2021


uweigand added a comment.

I don't think there is a s390x platform-specific problem involved here at all, so I'm not sure disabling the test for the platform is the right fix.

What seems to happen is:

- The test case intentionally compares the stack traces from two **different** invocations:

  (1) RunOneTest->ExecuteCallback->LLVMFuzzerTestOneInput->Bar
  (2) MinimizeCrashLoop->ExecuteCallback->LLVMFuzzerTestOneInput->Bar

- It just so happens that on s390x under these particular circumstances, the ExecuteCallback routine is *not* inlined into RunOneTest in (1), but it *is* inlined into MinimizeCrashLoop in (2).  This is the only platform-specific aspect of the whole scenario, and it does not indicate any bug or problem; it could happen elsewhere too.
- The llvm-symbolizer will retrieve the function name for normal (non-inlined) frames from the symbol table, but the function name for an inline frame from debug info.
- For C++ code, names found in the symbol table are mangled, and are printed in demangled form including the function prototype.   However, names found in debug info are just plain unmangled names, and are printed as such (without prototype).  This means that there is a difference in the printed output between inlined and non-inlined frames.  This difference causes the fuzzer test to fail.

In theory the symbolizer can probably be improved to also print the prototype for inlined C++ functions -- the argument type information is available in debug info too, it's just not encoded into the mangled name but rather into DWARF debug statements.  Those could also be decoded, but that would need to be implemented.  But I don't think this is really what **this** test is all about anyway.

Given the **current** symbolizer behavior, this test case implicitly assumes that the invocations of ExecuteCallback in (1) and (2) above are either both inlined or none of them are.  Therefore, I think Jonas' patch makes sense here, in that it ensure that this assumption is always met.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97975/new/

https://reviews.llvm.org/D97975



More information about the llvm-commits mailing list