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

[Laszlo Ersek <lersek@redhat.com>]

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