On 06.06.2025 09:22, Jan Beulich wrote: > On 05.06.2025 19:01, Andrew Cooper wrote: >> On 05/06/2025 2:24 pm, Jan Beulich wrote: >>> On 05.06.2025 14:14, Andrew Cooper wrote: >>>> On 05/06/2025 1:02 pm, Jan Beulich wrote: >>>>> On 05.06.2025 13:16, Andrew Cooper wrote: >>>> This really is a property of being a PE32+ binary, and nothing to do >>>> with EFI. >>> Which still can be checked for without having this code path being taken >>> for xen.gz, too: You could e.g. check for &efi > &_end. That's firmly an >>> image property (yet I expect you're going to sigh about yet another hack). >> >> It's all hacks, but no. >> >> I'm amazed MISRA hasn't spotted that we've got a global `struct efi >> efi;` and a label named efi, creating an alias for the object with it >> out of bounds in the compiled image. But even then, it's based on >> XEN_BUILD_EFI not XEN_BUILD_PE and does not distinguish the property >> that matters. > > The use of XEN_BUILD_EFI in the linker script should have been switched > to XEN_BUILD_PE when the split was introduced. > >> But the argument I'm going to make this this: Why do you want a check, >> even if you can find a correct one (and as said before, I cannot)? >> >> This function is run exactly once. We've excluded "nothing given by the >> toolchain", and excluded "what the toolchain gave us was not the >> expected ELF note". The only thing left (modulo toolchain bugs) is the >> CodeView region, and if it's not a valid CodeView region then we've >> wasted a handful of cycles. > > Two reasons: Having code which cannot possibly do anything useful isn't > good. Misra calls the latest the body of the inner if() "unreachable code" > and objects to the presence of such in a build. (I'm pretty sure Eclair > wouldn't spot it, but that doesn't eliminate this being a violation of > the respective rule.) > > And then, based on your reasoning above, why don't you also drop the > #ifdef CONFIG_X86?
..., saying in the description "we can as well check for this uniformly" Jan
