[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