On Wed, May 15, 2019 at 11:24 PM 'Nick Desaulniers' via Clang Built Linux clang-built-linux@googlegroups.com wrote:
On Wed, May 15, 2019 at 2:17 PM Arnd Bergmann arnd@arndb.de wrote:
On Wed, May 15, 2019 at 11:06 PM 'Nick Desaulniers' via Clang Built Linux clang-built-linux@googlegroups.com wrote:
On Wed, May 15, 2019 at 1:57 PM Arnd Bergmann arnd@arndb.de wrote:
Heh, https://github.com/ClangBuiltLinux/linux/issues/482#issuecomment-492828082 what's the difference between OABI and AEABI (honestly don't know enough about anything less than ARMv8)?
I don't understand kbuild enough to know why the line that starts with `bool` you added has `&& !CC_IS_CLANG`, but the default line you added is `|| CC_IS_CLANG`.
The added '&& !CC_IS_CLANG' means the option is invisible to users, i.e. the prompt is conditional. The second changed line is for the default, which is used when the option remains turned off.
Is the implication of your patch to always build w/ AEABI when building w/ clang? If so, what are the implications for the resulting image? Or do I have that wrong?
OABI is irrelevant for most users, and we should probably make it harder to accidentally use it for the kernel. EABI was introduced with gcc-4.3 in order to support Thumb2 user space (armv7, and arm1156t2), but was incompatible with the old Linux ELF ABI that we now call OABI, so we still allow building kernels using it, as well as supporting OABI binaries with an EABI kernel (CONFIG_OABI_COMPAT).
gcc has removed support for OABI user space a few years ago, but we can still get it to build OABI kernels for us, and there are still people with old user space that has exclusively OABI support. clang never had OABI support, and should not add it either.
Arnd