Laszlo Ersek [mailto:ler...@redhat.com] wrote:
]On 03/15/14 22:55, Scott Duplichan wrote:
]
]> I believe there is one exception to this rule. For x86 code (I tested x64
only),
]> the VA_START and VA_ARG macros defined by EDK2 work only for the Microsoft
]> x64 calling convention and not for Syste
On 03/15/14 22:55, Scott Duplichan wrote:
> I believe there is one exception to this rule. For x86 code (I tested x64
> only),
> the VA_START and VA_ARG macros defined by EDK2 work only for the Microsoft
> x64 calling convention and not for System V calling convention.
Ah, good point. Ran into t
Varargs and will
never be implemented in assembly.
Thanks,
Mike
-Original Message-
From: Andrew Fish [mailto:af...@apple.com]
Sent: Saturday, March 15, 2014 3:21 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EFIAPI Calling Convention
On Mar 15, 2014, at 2:55 PM, Scott
On Mar 15, 2014, at 2:55 PM, Scott Duplichan wrote:
> Andrew Fish [mailto:af...@apple.com] wrote:
>
> ]On Mar 11, 2014, at 6:17 PM, Ben Schroeder wrote:
> ]
> ]
> ] Hi,
> ]
> ] Regarding EFIAPI calling convention, the UEFI 2.3.1 specification
> ] writes:
> ]“All public interfaces of a
Andrew Fish [mailto:af...@apple.com] wrote:
]On Mar 11, 2014, at 6:17 PM, Ben Schroeder wrote:
]
]
] Hi,
]
] Regarding EFIAPI calling convention, the UEFI 2.3.1 specification
] writes:
]All public interfaces of a UEFI module must follow the UEFI calling
]convention. Public interface
I tested OVMF's size when adding -mabi=ms. Perhaps we should consider
adding it to the flags only for RELEASE builds. This would still allow
us to find EFIAPI bugs with DEBUG builds.
X64 GCC48 compared to GCC48 + -mabi=ms
DEBUG
SECFV: 43480 -> 42552 (2.1% savings)
FVMAIN_COMPACT: 976960 -> 960760
One other advantage is that this is the only way we can identify bugs
in EFIAPI usage.
Unfortunately, users of the GCC4X toolchains have to carry the burden
of debugging these issues.
Best case the compiler will generate a warning to point out the issue.
Worst case, someone uses an explicit type
I’m not sure why the __attribute__ is used vs. the entire calling convention it
did not do the GCC port. I maintain the clang toolchain, and the early work on
edk2 was done with VC++.
The EFIABI is also used on library APIs. The reason is if the library function
is implemented in assembler the
(apologies for butting in, I can't resist)
On 03/14/14 16:13, Ari Zigler wrote:
> Hi Andrew,
>
>
>
> Thanks for the clarification.
>
>
>
> We’re using GCC 4.6 and I saw in the tools_defs.txt that our EFIAPI
> definition is being mapped to GCC’s function attribute
> __attribute__(ms_abi) w
ame source code compiled with SYSV ABI.
Thanks,
Ari
From: Andrew Fish [mailto:af...@apple.com]
Sent: Wednesday, March 12, 2014 4:11 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EFIAPI Calling Convention
On Mar 11, 2014, at 6:17 PM, Ben Schroeder
mailto:ben...@mellanox.co
On Mar 11, 2014, at 6:17 PM, Ben Schroeder wrote:
> Hi,
>
> Regarding EFIAPI calling convention, the UEFI 2.3.1 specification writes:
> “All public interfaces of a UEFI module must follow the UEFI calling
> convention. Public interfaces include the image entry point, UEFI event
> handlers, a
Hi,
Regarding EFIAPI calling convention, the UEFI 2.3.1 specification writes:
"All public interfaces of a UEFI module must follow the UEFI calling
convention. Public interfaces include the image entry point, UEFI event
handlers, and protocol member functions. The type EFIAPI is used to indicate
12 matches
Mail list logo
