[cfe-dev] Questions on reproducibility/deterministic build
Oleksiy Obitotskyi -X (oobitots - GLOBALLOGIC INC at Cisco) via cfe-dev
cfe-dev at lists.llvm.org
Wed Jan 13 09:06:32 PST 2021
Hi,
I'm working on reproducibility (or deterministic build) issues with clang.
And I got issue with compiler-rt libraries, some of the debug symbols comes with source absolute path, e.g.:
strings ./build/lib64/linux/libclang_rt.fuzzer-x86_64.a | grep "lambda at"
...
---8<--- A
CollectFeatures<(lambda at /compiler-rt/lib/fuzzer/FuzzerDriver.cpp:482:25)>
...
---8<--- B
void fuzzer::TracePC::IterateInline8bitCounters(CallBack) [CallBack = (lambda at
<some-path>/compiler-rt/lib/fuzzer/FuzzerTracePC.cpp:77:29)]
void fuzzer::TracePC::IterateInline8bitCounters(CallBack) [CallBack = (lambda at
<some-path>/compiler-rt/lib/fuzzer/FuzzerTracePC.cpp:85:29)]
void fuzzer::TracePC::IterateInline8bitCounters(CallBack) [CallBack = (lambda at
<some-path>/compiler-rt/lib/fuzzer/FuzzerTracePC.cpp:99:29)]
void fuzzer::TracePC::IterateInline8bitCounters(CallBack) [CallBack = (lambda at
<some-path>/compiler-rt/lib/fuzzer/FuzzerTracePC.cpp:206:33)]
void fuzzer::TracePC::IterateCoveredFunctions(CallBack) [CallBack = (lambda at
<some-path>/compiler-rt/lib/fuzzer/FuzzerTracePC.cpp:314:34)]
---8<--- C
IterateInline8bitCounters<(lambda at /compiler-rt/lib/fuzzer/FuzzerTracePC.cpp:77:29)>
IterateInline8bitCounters<(lambda at /compiler-rt/lib/fuzzer/FuzzerTracePC.cpp:85:29)>
IterateInline8bitCounters<(lambda at /compiler-rt/lib/fuzzer/FuzzerTracePC.cpp:99:29)>
IterateInline8bitCounters<(lambda at /compiler-rt/lib/fuzzer/FuzzerTracePC.cpp:206:33)>
IterateCoveredFunctions<(lambda at /compiler-rt/lib/fuzzer/FuzzerTracePC.cpp:314:34)>
...
Conditions:
- clang version 7 used.
- flags -ffile-prefix-map/debug-prefix-map/macro-prefix-map <some-path> are set during compilation
- patch backported https://github.com/llvm/llvm-project/commit/56acd5a66ea3800a23be0cfdbc422624398cb096
In section A and C debug symbols for lambda have path correctly remapped with prefix set in -f<file/debug/macro>-prefix-map.
But section B debug symbols for the same lambda code goes without remapping (and it's ok TypePrinter code works properly in this case).
For section B TypePrinter::printTag called with PrintingPolicy.RemapFilePaths set, but for section A the same function called with different PrintingPolicy and RemapFilePaths is not set.
- I'm not sure is it ok that two sections generated in different way and what is the reason for this? The similar code with lambdas from section A produce only one symbol type with remapped path.
- Is it possible and is it make sense to pass CGDebugInfo settings to the code Sema::BuildPredefinedExpr to apply
RemapFilePaths settings to the PrintingPolicy used? As I understand symbols could be generated into different compilation stages/passes and some code generation settings could not be applied directly during other stages.
Regards,
Oleksiy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210113/0c26468f/attachment.html>
More information about the cfe-dev
mailing list