Use arch of the analizer machine instead of the original one. #1308
Conversation
|
It is by design that we use the target architecture since this is the only way to have multiple directories for multiple analysis on the same machine if the code is cross-compiled to different architectures at once. This is why it is important to get this arch setting from clang itself instead of relying on the current machine we are running on. The ctu-dir is supposed to have temporary stuff which is only good for the same clang arch and version. If you use these internals in a different version of clang (as I understand, you want to use an other clang on a different platform), there is no guarantee that things don't break. |
|
(...and I'm afraid we don't have tests for cross-compiled, multiple-arch-in-one-build projects, so be aware!) |
|
I thought it had a reason. But the other option fixing this would be a fix in the Clang code base where this externalFnMap is read. |
|
So what is the issue itself? Clang tries to read the externalFnMap from its own triple path instead of using the triple generated from the command that is getting analysed? |
whisperity
added
the
analyzer 📈
bruntib
force-pushed
the
arch_triple_fix
branch
from
a66a4e5 to
f8f79d8
Compare
When creating the content of the ctu-dir the target architecture was used to which compilation happened. If the analysis runs on a different architecture (e.g. for debugging reasons) then the analyzer can't find the necessary files of which the paths are named after the architecture.
bruntib
force-pushed
the
arch_triple_fix
branch
from
f8f79d8 to
dc2cd42
Compare
|
OK, other solution uploaded. |
whisperity
added
dev env ⛑️
| if flag.startswith('--target='): | ||
| return flag[9:].split('-')[0] # 9 == len('--target=') | ||
|
|
||
| return platform.machine() |
There was a problem hiding this comment.
Would platform.machine() return the same string which clang uses when --target is not given?
There was a problem hiding this comment.
Debatable. What happens if the architecture of Python and Clang differs, exactly one of them is 32-bit?
There was a problem hiding this comment.
This is just a fallback in case there is no --target given in the clang command invocation. This platform.machine() returns the architecture of the current machine where this Python script is run. If it differs from the one on which the build action was run, then it still doesn't work, like before this patch.
There was a problem hiding this comment.
Ok, let's merge it now because we need this badly and most often --target is given.
|
@gerazo Recently we changed CTU code in Clang to not allow merging ASTs from different targets. |
When creating the content of the ctu-dir the target architecture was
used to which compilation happened. If the analysis runs on a different
architecture (e.g. for debugging reasons) then the analyzer can't find
the necessary files of which the paths are named after the architecture.