linux-kernel - Re: [PATCH] drm/amdgpu: Re-enable DCN for 64-bit powerpc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87mtcwbsz3.fsf@mpe.ellerman.id.au>
Date:   Tue, 26 Jul 2022 10:47:12 +1000
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Guenter Roeck <linux@...ck-us.net>,
        Segher Boessenkool <segher@...nel.crashing.org>,
        Timothy Pearson <tpearson@...torengineering.com>
Cc:     Dan Horák <dan@...ny.cz>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        amd-gfx <amd-gfx@...ts.freedesktop.org>,
        Alex Deucher <alexdeucher@...il.com>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH] drm/amdgpu: Re-enable DCN for 64-bit powerpc

Guenter Roeck <linux@...ck-us.net> writes:
> On 7/25/22 13:42, Segher Boessenkool wrote:
>> On Mon, Jul 25, 2022 at 02:34:08PM -0500, Timothy Pearson wrote:
>>>>> Further digging shows that the build failures only occur with compilers
>>>>> that default to 64-bit long double.
>>>>
>>>> Where the heck do we have 'long double' things anywhere in the kernel?
>>>>
>>>> I tried to grep for it, and failed miserably. I found some constants
>>>> that would qualify, but they were in the v4l colorspaces-details.rst
>>>> doc file.
>>>>
>>>> Strange.
>>>
>>> We don't, at least not that I can see.  The affected code uses standard doubles.
>>>
>>> What I'm wondering is if the compiler is getting confused between standard and long doubles when they are both the same bit length...
>> 
>> The compiler emits the same code (DFmode things, double precision float)
>> in both cases, and it itself does not see any difference anymore fairly
>> early in the pipeline.  Compare to int and long on most 32-bit targets,
>> both are SImode, the compiler will not see different types anymore:
>> there *are* no types, except in the compiler frontend.
>> 
>> It only happens for powerpc64le things, and not for powerpc64 builds.
>> 
>> It is probably a GCC problem.  I don't see what forces the GCC build
>> here to use 64-bit long double either btw?  Compilers build via buildall
>> have all kinds of unnecessary things disabled, but not that, not
>> directly at least.
>> 
>
>  From what little documentation I can find, there appears to be
> "--with-long-double-128" and "--with-long-double-format=ieee".
> That looks like something that would need to be enabled, not disabled.
>
> FWIW, depending on compiler build options such as the above for kernel
> builds seems to be a little odd to me, and I am not sure I'd want to
> blame gcc if the kernel wants to be built with 128-bit floating point
> as default.

The kernel doesn't care what the size is, but ld refuses to link objects
built with soft/hard float if the long double size is 64-bits.

> At the very least, that should be documented somewhere,
> and if possible the kernel should refuse to build if the compiler build
> options don't meet the requirements.

The ABI says long double is 128-bits. So it's documented there :)

The kernel expects that passing `-m64 -mlittle-endian -mabi=elfv2` will
produce code that conforms to the 64-bit Little Endian ELFv2 ABI :D

But it seems those flags are not sufficient.

There is an -mlong-double-128 flag, which appears to do the right thing
regardless of how the compiler was built. I will probably add that to
the kernel CFLAGS, but that's not a change I want to do just before the
v5.19 release.

cheers