> On Jul 24, 2015, at 3:33 AM, David Woodhouse <[email protected]> wrote: > > On Fri, 2015-07-24 at 00:08 +0200, Laszlo Ersek wrote: >> >>> Any non-EFIAPI function using varargs is broken, isn't it? >> >> Correct, with one tweak: any non-EFIAPI function accessing varargs with >> the VA_* macros from Base.h is broken. > > Can we *make* them break? I don't know, something like 'volatile > unsigned long dummy_ecx __asm__("ecx")' where ECX is a reserved > register in the SYSV ABI but not MS? > > I know, that's a *really* bad example and I don't think you can even > assign variables to registers like that any more. But it's just an > illustration; can we come up with *something* that makes the VA_LIST > macro break at *build* time from a non-EFIAPI function? Ideally on > *all* builds, but at least for x86_64 ELF. > > An artificial way to keep us honest w.r.t. EFIAPI annotations would > also be nice, if Jordan insists on keeping it working. I wonder if we > can put them in a separate section, and have a script post-process the > objects looking for discrepancies? I also thought about prepending > something to the function names, but I can't see how that could be made > to work. Any other ideas? >
David, I like the creativity. The problem is optimization. Functions can get inlined, tail called, or the calling conventions can be made up by the compiler as an optimization. So in general you can’t assume any behavior is illegal. The flip side of this is I use a debugger that has no clue what EFIAPI is for x86_64, but it works fine as the debugger can’t make any assumptions due to the compiler making optimizations. The main reason we don’t map EFIAPI to anything is that the compiler is smart enough to know that a function is getting exported in some fashion and can’t thus can’t be optimized, and must follow the ABI. Maybe it would be possible to have the compiler warn if an ABI function is not decorated with EFIAPI, it would catch all errors, but it may get a lot of false positives too (might not even be possible at -O0)? Hey but if you get around to hacking the compiler it would be awesome to add support for the edk2 Print format strings. That way we would get type warnings if the arguments don’t match the format specifiers, just like printf. For gcc/clang this syntax enables all the printf format string vs. argument warns for my_printf that exist with printf. int my_printf (void *my_object, const char *my_format, ...) __attribute__ ((format (printf, 2, 3))); It might be possible to add a format attribute to a function that could check the calling conventions, but the optimizations may happen too late to help? Thanks, Andrew Fish > -- > dwmw2 > > -- > David Woodhouse Open Source Technology Centre > [email protected] Intel Corporation _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
