[PATCH] drm/amdgpu: make DRM_AMD_DC x86-only again
Nick Desaulniers
ndesaulniers at google.com
Tue Dec 8 18:21:02 UTC 2020
On Tue, Dec 8, 2020 at 6:26 AM Arnd Bergmann <arnd at kernel.org> wrote:
>
> On Mon, Dec 7, 2020 at 11:28 PM 'Nick Desaulniers' via Clang Built
> Linux <clang-built-linux at googlegroups.com> wrote:
> >
> > On Mon, Dec 7, 2020 at 2:17 PM Arnd Bergmann <arnd at kernel.org> wrote:
> > >
> > > On Mon, Dec 7, 2020 at 11:08 PM 'Nick Desaulniers' via Clang Built
> > > Linux <clang-built-linux at googlegroups.com> wrote:
> > > >
> > > > On Mon, Dec 7, 2020 at 1:57 PM Arnd Bergmann <arnd at 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 at 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?
--
Thanks,
~Nick Desaulniers
More information about the amd-gfx
mailing list