On Tue, Dec 8, 2020 at 6:26 AM Arnd Bergmann arnd@kernel.org wrote:
On Mon, Dec 7, 2020 at 11:28 PM 'Nick Desaulniers' via Clang Built Linux clang-built-linux@googlegroups.com wrote:
On Mon, Dec 7, 2020 at 2:17 PM Arnd Bergmann arnd@kernel.org wrote:
On Mon, Dec 7, 2020 at 11:08 PM 'Nick Desaulniers' via Clang Built Linux clang-built-linux@googlegroups.com wrote:
On Mon, Dec 7, 2020 at 1:57 PM Arnd Bergmann arnd@kernel.org wrote:
Right, looking at my latest randconfig logs, I see the same problem on x86 builds with clang as well, though I'm not entirely sure which other configuration options are needed to trigger it.
So my patch can be disregarded, but I agree this needs a better fix, either in clang or in the dcn driver.
If you could give https://github.com/ClangBuiltLinux/frame-larger-than a spin again, I would appreciate any feedback.
I've already tried it, but the tool doesn't seem to like me, I never get the information out of it that I want. This time it failed because it could not parse the .o file correctly.
The tool has a dependency on a python library for parsing ELF; I've been having to teach it about various relocation types for non-x86_64 architectures; I'm sure the failure from that scenario is...gnarly. I don't know if my latest aarch64 fixes have been deployed (and it depends on how the library is distributed).
Can you send me a config to reproduce the .o file?
The one attached here should reproduce it on x86.
Hmm...no warnings for me with that config on next-20201208: $ make LLVM=1 -j71 olddefconfig $ make LLVM=1 -j71 ... $ clang --version clang version 12.0.0 (git@github.com:llvm/llvm-project.git 1c98f984105e552daa83ed8e92c61fba0e401410) (ie. near ToT LLVM)
I see CONFIG_KASAN=y in the .config, so that's a recurring theme with clang; excessive stack usage. It does seem a shame to disable a driver for a bunch of archs just due to KASAN stack usage. $ grep KASAN=y 0x9077925C_defconfig CONFIG_HAVE_ARCH_KASAN=y CONFIG_KASAN=y
Is there a different branch of a different tree that I should be testing on instead? Otherwise, can you send the object file?