• Masahiro Yamada's avatar
    kconfig: introduce m32-flag and m64-flag · 8cc4fd73
    Masahiro Yamada authored
    When a compiler supports multiple architectures, some compiler features
    can be dependent on the target architecture.
    
    This is typical for Clang, which supports multiple LLVM backends.
    Even for GCC, we need to take care of biarch compiler cases.
    
    It is not a problem when we evaluate cc-option in Makefiles because
    cc-option is tested against the flag in question + $(KBUILD_CFLAGS).
    
    The cc-option in Kconfig, on the other hand, does not accumulate
    tested flags. Due to this simplification, it could potentially test
    cc-option against a different target.
    
    At first, Kconfig always evaluated cc-option against the host
    architecture.
    
    Since commit e8de12fb ("kbuild: Check for unknown options with
    cc-option usage in Kconfig and clang"), in case of cross-compiling
    with Clang, the target triple is correctly passed to Kconfig.
    
    The case with biarch GCC (and native build with Clang) is still not
    handled properly. We need to pass some flags to specify the target
    machine bit.
    
    Due to the design, all the macros in Kconfig are expanded in the
    parse stage, where we do not know the target bit size yet.
    
    For example, arch/x86/Kconfig allows a user to toggle CONFIG_64BIT.
    If a compiler flag -foo depends on the machine bit, it must be tested
    twice, one with -m32 and the other with -m64.
    
    However, -m32/-m64 are not always recognized. So, this commits adds
    m64-flag and m32-flag macros. They expand to -m32, -m64, respectively
    if supported. Or, they expand to an empty string if unsupported.
    
    The typical usage is like this:
    
      config FOO
              bool
              default $(cc-option,$(m64-flag) -foo) if 64BIT
              default $(cc-option,$(m32-flag) -foo)
    
    This is clumsy, but there is no elegant way to handle this in the
    current static macro expansion.
    
    There was discussion for static functions vs dynamic functions.
    The consensus was to go as far as possible with the static functions.
    (https://lkml.org/lkml/2018/3/2/22)
    Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
    Tested-by: default avatarGeorge Spelvin <lkml@sdf.org>
    Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
    8cc4fd73
Kconfig.include 1.81 KB