Questions on reproducibility/deterministic build

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Questions on reproducibility/deterministic build

Deep Majumder via cfe-dev

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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Questions on reproducibility/deterministic build

Deep Majumder via cfe-dev
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 <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Questions on reproducibility/deterministic build

Deep Majumder via cfe-dev

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 <[hidden email]>
Sent: Wednesday, January 13, 2021 22:45
To: Oleksiy Obitotskyi -X (oobitots - GLOBALLOGIC INC at Cisco)
Cc: [hidden email]; 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 <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

0001-Honor-fdebug-prefix-map-when-creating-function-names.patch (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Questions on reproducibility/deterministic build

Deep Majumder via cfe-dev
Yeah, sorry - that's a bit too involved for me to get into at the
moment (& a somewhat older version of clang too - LLVM point releases
are generally only for the last release, not as far back as 7.0, so
even if we figured out what it was, if it doesn't reproduce in more
recent clang, there's probably nothing to be done here)

On Mon, Jan 18, 2021 at 12:11 AM Oleksiy Obitotskyi -X (oobitots -
GLOBALLOGIC INC at Cisco) <[hidden email]> wrote:

>
> 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 <[hidden email]>
> Sent: Wednesday, January 13, 2021 22:45
> To: Oleksiy Obitotskyi -X (oobitots - GLOBALLOGIC INC at Cisco)
> Cc: [hidden email]; 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 <[hidden email]> 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
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev