svn commit: r321284 - in head/sys: amd64/include sys

[Ryan Libby]

On Thu, Jul 20, 2017 at 3:33 AM, Konstantin Belousov
<kostikbel at gmail.com> wrote:
> On Thu, Jul 20, 2017 at 02:08:30AM -0700, Ryan Libby wrote:
>> On Thu, Jul 20, 2017 at 1:01 AM, Bruce Evans <brde at optusnet.com.au> wrote:
[...]
>> > This bug is not very common.  There seem to be no instances of it in
>> > <sys> (only sys/cdefs.h uses __attribute__(()), and it seems to use
>> > underscores for all the attributes).  Grepping sys/include/*.h for
>> > attribute shows the following bugs:
>> >
>> > X amd64/include/efi.h:#define   EFIABI_ATTR     __attribute__((ms_abi))
>> > X i386/include/efi.h:#define    EFIABI_ATTR /* __attribute__((ms_abi)) */ /* clang fails with this */
>> > X ofed/include/rdma/ib_user_mad.h:typedef unsigned long __attribute__((aligned(4))) packed_ulong;
>> > X ofed/include/rdma/ib_smi.h:} __attribute__ ((packed));
>> > X ofed/include/rdma/ib_mad.h:} __attribute__ ((packed));
>> > X ofed/include/rdma/ib_mad.h:} __attribute__ ((packed));
>> >
>> > The commented-out ms_abi was only a style bug.  Now it is a larger style
>> > bug -- it is different and worse than amd64.
>>
>> I'm not sure what to do about i386 there (again beyond fixing up the
>> spelling in the comment).  Maybe the unsupported architectures should
>> just not be declaring EFIABI_ATTR at all?  (Thoughts, kib?)
>
> I think i386 should be treated exactly same as amd64, i.e. EFIABI_ATTR
> should be not defined if gcc < 4.4. Or I do not understand the scope
> of the question.

After googling around [1] and a quick check of the spec [2], it now
seems to me that the i386 comment might just be erroneous.  I think the
right solution for sys/i386/include/efi.h may just be to delete the
comment and leave that EFIAPI_ATTR macro definition as empty (always, no
compiler version check) in order to use the native calling convention.

[1] http://wiki.osdev.org/UEFI#Calling_Conventions
[2] http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf