Re: [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

[Jordan Justen <jordan.l.justen@intel.com>]

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.

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