> On Nov 5, 2014, at 2:00 AM, Laszlo Ersek <[email protected]> wrote:
>
> On 11/05/14 00:02, Andrew Fish wrote:
>>
>>> On Nov 4, 2014, at 2:32 PM, Jordan Justen <[email protected]> wrote:
>>>
>>> On Tue, Nov 4, 2014 at 9:28 AM, Andrew Fish <[email protected]> wrote:
>>>> So my 1st question is why do you need to mix calling conventions, and
>>>> depend
>>>> on EFIAPI for interoperability. Why not just change the ABI on all
>>>> functions?
>>>
>>> GCC 4.4 doesn't support the command line option to change everything
>>> over. So, EFIAPI was the only option then.
>>>
>>>> Problems with the mixed calling convention:
>>>> 1) All assembly routines must be marked as EFIAPI, or the C code will
>>>> generate the wrong calling convention. Not an issue in the MdePkg, but
>>>> potentially an issue in other packages.
>>>
>>> I don't see this as a problem. I think this is the rules that we have
>>> set up for EDK II. It just so happens that the GCC4X toolchains are
>>> the only ones that use EFIAPI, and thus are the only ones that allow
>>> us to keep our codebase clean with regards to EFIAPI.
>>>
>>
>> I agree it is good in keeping the edk2 code clean. I was more concerned
>> about code from 3rd parties.
>> So sorry this was more about a warning when you are porting code on what to
>> look out for.
>>
>> I’m really only concerned about how the VA_LIST stuff is going to
>> work? Does it need to shift for native vs. EFIAPI? If so how you pass
>> the VA_LIST around if the code is not all the same ABI?
>
> We need to distinguish passing arguments through the ellipsis (...) from
> passing VA_LIST (as a normal, named parameter).
>
> For passing arguments through the ellipsis (...), the called function
> *must* be EFIAPI (in the current state of the tree). Otherwise
> VA_START() won't work in the callee.
>
> (BTW I have no problem with the above "restriction".)
>
> Regarding passing VA_LIST by name (which is identical to passing a
> simple CHAR8* by name) -- it already works fine, regardless of EFIAPI
> vs. no-EFIAPI.
>
OK thanks for the info. For some flavors of GCC the __buildin_va_list is a
structure. Since the size of the structure is > 8 bytes it is passed via a
pointer per the calling conventions. For X64 EFIAPI VA_LIST is a pointer to
the frame where the register based arguments have have been spilled.
For clang x86_64 __buildin_va_list is also a structure, so you can’t mix and
match.
Thanks,
Andrew Fish
~/work/Compiler>cat vv.c
#include <stdarg.h>
#include <stdio.h>
int
main ()
{
printf ("sizeof __builtin_va_list %lu\n", sizeof (__builtin_va_list));
return 0;
}
~/work/Compiler>clang vv.c
~/work/Compiler>./a.out
sizeof __builtin_va_list 24
~/work/Compiler>clang -arch i386 vv.c
~/work/Compiler>./a.out
sizeof __builtin_va_list 4
~/work/Compiler>
> The problem discussed in this thread is unrelated to EFIAPI. The problem
> is (apparently) that gcc's -Os optimization corrupts a local variable in
> a chain of recursive calls.
>
>>> For GCC >= 4.5, I actually think we should convert *RELEASE* builds
>>> over to using the ms-abi all the time to generate smaller code. I
>>> think we should leave DEBUG builds as mixed to help clean up EFIAPI
>>> issues.
>>>
>>
>> You guys should figure out if you can have a ms-abi but add the frame
>> pointers. The compiler is open source ….
>
> In my experimentation yesterday, one of the first things I tried (on
> "gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16)") was
> '-fno-omit-frame-pointer'.
>
> Because, '-Os' implies '-fomit-frame-pointer', and at that point I
> thought that maybe '-fomit-frame-pointer', incurred by '-Os', was
> causing the issue.
>
> So, I added '-fno-omit-frame-pointer' *after* -Os.
>
> It triggered a "sorry, unimplemented" bug, which was very similar to
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59927
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59927>>:
>
> sorry, unimplemented: ms_abi attribute requires
> -maccumulate-outgoing-args or subtarget optimization implying it
>
> However, after appending '-maccumulate-outgoing-args' as well, the build
> resumed. (To clarify, this meant:
>
> -Os -fno-omit-frame-pointer -maccumulate-outgoing-args
>
> .) Unfortunately, although the tree did build like this, the original
> issue persisted. Which I took as proof that the bug was unrelated to
> reserving or not reserving %rbp as frame pointer.
>
> I wish I could write a small reproducer for this problem...
>
>>
------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
