On Tue, Dec 8, 2020 at 6:26 AM Arnd Bergmann <arnd@xxxxxxxxxx> wrote: > > On Mon, Dec 7, 2020 at 11:28 PM 'Nick Desaulniers' via Clang Built > Linux <clang-built-linux@xxxxxxxxxxxxxxxx> wrote: > > > > On Mon, Dec 7, 2020 at 2:17 PM Arnd Bergmann <arnd@xxxxxxxxxx> wrote: > > > > > > On Mon, Dec 7, 2020 at 11:08 PM 'Nick Desaulniers' via Clang Built > > > Linux <clang-built-linux@xxxxxxxxxxxxxxxx> wrote: > > > > > > > > On Mon, Dec 7, 2020 at 1:57 PM Arnd Bergmann <arnd@xxxxxxxxxx> 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@xxxxxxxxxx: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? -- Thanks, ~Nick Desaulniers _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
