On Sun, 7 Nov 2021 at 23:54, Seed Of Onan <seedofonan@xxxxxxxxx> wrote: > > What follows is just IMHO. Seriously -- I sincerely appreciate you even considering doing anything at all about my nothing issue, and I expect no further involvement in the decision as to what is done about it. > > > I don't follow. All compilers that we support implement this so why test for it? > Okay. And how does one discover if one's compiler (and environment and platform) is one "that we support" for any given combination of kernel configurations and mix of options? For instance, is mine and how do I find out? I'm presently under the spell of thinking that the contents of Kconfig DEFINES what "we" support. So in answer to your question, I'm thinking we keep the existing test because it specifies a real, additional burden on any past/present/future compiler, and without it we are saying that any past/present/future compiler should (is supported to) work now because there is no longer any such additional burden -- older x86_64 compilers and environments that once failed the -mabi=ms test, they are now supported if no other test says otherwise. In short, I don't know if "we" should keep it (modified, I hope) or not, but I expect you (all) are better qualified to decide both that and the philosophical point of Kconfig in the first place. > It's very simple: we support GCC 5.1 or newer. But as you pointed out, the -m64 option is missing from the ms_abi test, leading to false negatives if m64 is not the default. Anyone is free to shoot themselves in the foot if they want to try and build the kernel with a non-supported compiler: the only impact that dropping this config check will have is that instead of disabling CONFIG_EFI_STUB automatically, it may get enabled and cause a build error. This is not a big deal as a) the compiler was not supported to begin with, and b) the user can just disable it, as the feature was not available to them in the first place. > > Note that 32-bit UEFI code uses __attribute__((regparm(0))) > > as the calling convention not ms_abi > Interesting, thanks. So that leads me to think the test should be, for hypothetical macro cc-attribute, like: > (X86_64 && $(cc-attribute, ms_abi)) || (X86_32 && $(cc-attribute, regparm(0))) > Again, the check is pointless so it needs to be dropped. It only decides whether or not EFI_STUB can be enabled or not, and with a non-supported compiler, we are in DYI territory anyway, so the user should just disable it themselves if their compiler is not compatible with the option.
