On 12/02/16 01:58, Jordan Justen wrote: > On 2016-12-01 12:54:34, Laszlo Ersek wrote: >> On 12/01/16 21:06, Jordan Justen wrote: >>> On 2016-12-01 10:43:24, Laszlo Ersek wrote: >>>> Hrpmf, wait a second, I do see something interesting: in this series you >>>> *are* modifying APIs declared in a library class header (namely >>>> "OvmfPkg/Include/Library/XenHypercallLib.h"). Such functions (public >>>> libraries) *are* required to specify EFIAPI. >>>> >>>> What happens if you apply patch #1 only? >>> >>> I agree that this should be fixed. >>> >>> But, if it works, I'm concerned that it would just be hiding a bug. My >>> understanding was that the EFIAPI on libraries was needed so that a >>> library implementation could be assembly based if desired. In this >>> case C is used for the implementation, so the calling conventions >>> should align. >> >> Never tried the following, so I'm unsure if edk2 intends to support it >> explicitly, but what about binary-only library instances (the 2-clause >> BSDL allows that)? > > Good point. Once again, I agree that it is a bug that needs to be > fixed. The functions in the library interface should have EFIAPI. > > I was just pointing out that I don't think it *ought* be the issue > here since both side are C, and being built by the same compiler.
Got it now. :) Thanks! Laszlo > Like you mentioned ... maybe it is a compiler bug, or a bug with our > build flags. > > -Jordan > >> If the library class header doesn't state EFIAPI on the functions, the >> library vendor builds the library instance with Visual Studio, and the >> library user builds the client module with gcc (against the same library >> class header), calls will fail. >> >> (The way I imagine using binary-only library instances is that the >> library comes as a binary object with a matching INF file, in a separate >> subdirectory, and the user resolves the library class in his/her >> platform DSC to that INF file. Not sure about the exact [section names] >> in the library instance's INF file though.) >> >> Thanks! >> Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
