On 11/05/14 00:02, Andrew Fish wrote: > >> On Nov 4, 2014, at 2:32 PM, Jordan Justen <jljus...@gmail.com> wrote: >> >> On Tue, Nov 4, 2014 at 9:28 AM, Andrew Fish <af...@apple.com> 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. 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>: 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... > > Thanks, > > Andrew Fish > >> -Jordan > > > ------------------------------------------------------------------------------ > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel > ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
