Page MenuHomePhabricator

Exploratory patch - capture DebugInfo for constexpr variables used within lambda
Needs ReviewPublic

Authored by mibintc on Sep 2 2020, 11:54 AM.

Details

Reviewers
None
Group Reviewers
debug-info
Summary

This is an exploratory patch, an attempt to solve bugs.llvm.org/show_bug.cgi?id=47400

That bug report shows a simple test case where the constexpr variable, declared outside the scope of the lambda but used within the lambda, is simply unknown in the DebugInfo. This is different from a gcc compilation where gdb knows the symbol, and knows that the value is "optimized out".

The problem is constexpr variables like n_steps (see example in the bug report) are not captured and so do not appear in the record type. These still appear in the AST so if we gather them it is possible to emit static data member. As a proof of concept, this is prototyped here. I didn't think about exactly which variables should be gathered but this might be a framework. This is a little hacky since the constexpr variable is not really a static member of the lambda but the use is roughly correct.

Diff Detail

Unit TestsFailed

TimeTest
128,130 mslinux > libFuzzer.libFuzzer::only-some-bytes-fork.test
Script: -- : 'RUN: at line 5'; /mnt/disks/ssd0/agent/llvm-project/build/./bin/clang --driver-mode=g++ -O2 -gline-tables-only -fsanitize=address -I/mnt/disks/ssd0/agent/llvm-project/compiler-rt/lib/fuzzer -m64 -c -fno-sanitize=all -fsanitize=dataflow -mllvm -dfsan-fast-16-labels /mnt/disks/ssd0/agent/llvm-project/compiler-rt/test/fuzzer/../../lib/fuzzer/dataflow/DataFlow.cpp -o /mnt/disks/ssd0/agent/llvm-project/build/projects/compiler-rt/test/fuzzer/X86_64DefaultLinuxConfig/Output/only-some-bytes-fork.test.tmp-DataFlow.o

Event Timeline

mibintc created this revision.Sep 2 2020, 11:54 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 2 2020, 11:54 AM
mibintc requested review of this revision.Sep 2 2020, 11:54 AM

I think it'd be helpful to discuss what the DWARF does and should look like in this case (I wonder if, maybe, the better solution is in the DWARF consumer - to do name lookup out through the lambda) - could you provide some summarized llvm-dwarfdump output comparisons between Clang (with/without the patch applied) and GCC's output?

I think it'd be helpful to discuss what the DWARF does and should look like in this case (I wonder if, maybe, the better solution is in the DWARF consumer - to do name lookup out through the lambda) - could you provide some summarized llvm-dwarfdump output comparisons between Clang (with/without the patch applied) and GCC's output?

I attached the 3 dwarf dumps into the bugzilla report. I'm not a dwarf expert, hope someone knowledgeable can take a look and summarize.