[cfe-dev] Questions on reproducibility/deterministic build

Mon Jan 18 00:11:47 PST 2021

Hi David,


I have to notice that I tried to reproduce the same isue for clang-9.0 Zeus but without success.

So seems that it's actual only for Thud clang-7.1.


I'm not sure if it worth doing but anyway here is how to reproduce:


I'm using standalone openembedded-core to reproduce.

- setup workspace https://www.openembedded.org/wiki/OE-Core_Standalone_Setup

- apped meta-clang layer: git clone https://github.com/kraj/meta-clang.git

- checkout oe-core, meta-clang with thud and bitbake with 1.40

- patch clang with https://github.com/llvm/llvm-project/commit/56acd5a66ea3800a23be0cfdbc422624398cb096. Actually patch need some manual work, so I attached already modified.

- add extra option for work-shared:

diff --git a/recipes-devtools/clang/compiler-rt_git.bb b/recipes-devtools/clang/compiler-rt_git.bb
index 05de71f..b201814 100644
--- a/recipes-devtools/clang/compiler-rt_git.bb
+++ b/recipes-devtools/clang/compiler-rt_git.bb
@@ -25,6 +25,8 @@ DEPENDS_append_class-nativesdk = " clang-native"
 THUMB_TUNE_CCARGS = ""
 #TUNE_CCARGS += "-nostdlib"

+DEBUG_PREFIX_MAP += " -fdebug-prefix-map=${S}=. "
+


- enable DEBUG_PREFIX_MAP


diff --git a/classes/clang.bbclass b/classes/clang.bbclass
index 4d20ff0..5b24fe8 100644
--- a/classes/clang.bbclass
+++ b/classes/clang.bbclass
@@ -30,7 +30,7 @@ TOOLCHAIN_class-crosssdk = "gcc"
 TOOLCHAIN_class-cross = "gcc"

 # -fmacro-prefix-map does not exist in clang 7.x
-DEBUG_PREFIX_MAP_toolchain-clang = " "
+#DEBUG_PREFIX_MAP_toolchain-clang = " "


- switch toolchain to clang: append TOOLCHAIN = "clang" to the conf/local.conf

- build clang-native: bitbake clang-native

- build compiler-rt: bitbake compiler-rt

- test for symbols:


strings <ws>/build/tmp-glibc/work/core2-64-oe-linux/compiler-rt/7.1.0-r0/build/lib/linux/libclang_rt.fuzzer-x86_64.a | grep "lambda at" | grep "Iterate"


void fuzzer::TracePC::IterateInline8bitCounters(CallBack) const [CallBack = (lambda at /home/oobitots/temp/oe-core/build/tmp-glibc/work-shared/llvm-project-source-7.1.0-r0/git/compiler-rt/lib/fuzzer/FuzzerTracePC.cpp:77:29)]
void fuzzer::TracePC::IterateInline8bitCounters(CallBack) const [CallBack = (lambda at /home/oobitots/temp/oe-core/build/tmp-glibc/work-shared/llvm-project-source-7.1.0-r0/git/compiler-rt/lib/fuzzer/FuzzerTracePC.cpp:85:29)]
void fuzzer::TracePC::IterateInline8bitCounters(CallBack) const [CallBack = (lambda at /home/oobitots/temp/oe-core/build/tmp-glibc/work-shared/llvm-project-source-7.1.0-r0/git/compiler-rt/lib/fuzzer/FuzzerTracePC.cpp:99:29)]
void fuzzer::TracePC::IterateInline8bitCounters(CallBack) const [CallBack = (lambda at /home/oobitots/temp/oe-core/build/tmp-glibc/work-shared/llvm-project-source-7.1.0-r0/git/compiler-rt/lib/fuzzer/FuzzerTracePC.cpp:206:33)]
void fuzzer::TracePC::IterateCoveredFunctions(CallBack) [CallBack = (lambda at /home/oobitots/temp/oe-core/build/tmp-glibc/work-shared/llvm-project-source-7.1.0-r0/git/compiler-rt/lib/fuzzer/FuzzerTracePC.cpp:314:34)]
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)>



Regards,

Oleksiy


________________________________
From: David Blaikie <dblaikie at gmail.com>
Sent: Wednesday, January 13, 2021 22:45
To: Oleksiy Obitotskyi -X (oobitots - GLOBALLOGIC INC at Cisco)
Cc: cfe-dev at lists.llvm.org; Taras Kondratiuk (takondra); Ruslan Bilovol -X (rbilovol - GLOBALLOGIC INC at Cisco)
Subject: Re: [cfe-dev] Questions on reproducibility/deterministic build

Could you provide a small standalone example and precise commands to reproduce the case you're describing?

On Wed, Jan 13, 2021 at 9:06 AM Oleksiy Obitotskyi -X (oobitots - GLOBALLOGIC INC at Cisco) via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:

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

_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210118/23469713/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Honor-fdebug-prefix-map-when-creating-function-names.patch
Type: text/x-patch
Size: 4575 bytes
Desc: 0001-Honor-fdebug-prefix-map-when-creating-function-names.patch
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210118/23469713/attachment-0001.bin>
