Of all the gin joints in all the towns in all the world, Andrew Fish had to walk into mine at 11:44:50 on Friday 07 November 2014 and say:
> > On Nov 7, 2014, at 10:32 AM, Kinney, Michael D > > <michael.d.kin...@intel.com> wrote: > > > > Andrew, > > > > Adding XCODE as a build rule family is possible. Your observation that > > both file extensions and build rule family can be used to select the > > correct build rule. > > > > The justification for adding a new build rule family is if there is a > > family of build tools that are not compatible with the current set of > > families. Do you believe XCODE requires different processing steps that > > any of the exiting build rule families? Can you provide a summary of > > the differences? > > Mike, > > To be clear XCODE is already a *_*_*_*BUILDRULEFAMILY, but uses GCC for s a > *_*_*_*FAMILY. I think we need to either add Xcode as a FAMILY, or add > support for BUILDRULEFAMILY overrides in INF files. Both of these > solutions work. > > When we started the XCODE target, Xcode was a version of GCC. At this point > it has converted to clang. To be fare clang tries to be command line > compatible with GCC to make it easy to switch, but clang does support > things that GCC does not. > > Xcode has its own BUILDRULESTARGET and > https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/Conf/build_rule.t > emplate has 9 references to XCODE. So the build process is different than > GCC. You can also see references to XCODE in some of the DSC files. > > In general the Xcode assembly support is a subset of GCC. So you have to > use .globl and not .global, this is why ASM_GLOBAL was added for example. > Some of the code generation seems to be a little different with Xcode, and > this has caused thrash when trying to maintain mode switching code like > Thunk16.S. The Xcode linker for X64 also imposes extra restrictions as it > does not support 32-bit addressing (Mac x86_64 apps fault on the 1st 4GB > of the address space so there is no point). The Xcode linker also does not > support the same set of relocations as GCC, so for IP relative addressing > has to be used in the assembly code. > > Historically I’ve periodically gone back a cleaned up the edk2 assembler to > work with Xcode, as what works in Xcode usually works in GCC (other than > the mode shift hackery). I’m happy with the status quo, and have no > issues. Unfortunately the edk2 GCC maintainers are not happy with the > status quo and would like to start a transition to NASM. Even if we remove > the two show stopper bugs with Xcode and NASM it is still a regression in > our minds to convert the MdePkg/MdeMoudlePkg to NASM. Thus I’m proposing > these changes to the build system, or promoting XCODE to a FAMILY so I > don’t hold back the edk2 GCC maintainers adoption of NASM. > > If the UDK2014.SP* was to require NASM to build the XCODE targets we are > going to fork it (we already have) to use .S files. We are also going to > push the fork back to our vendors. So this spilt out of XCODE is also an > attempt to prevent the need to have different forks of UDK2014.SP* > floating around. > > On the NASM front assuming the two Xcode show stoppers (no dead stripping, > no source level debug) get fixed switching to NASM is still a step > backwards for us: > 1) requires an extra tools, we are going to end up having the check into > our source base. > 2) Requires executive approval to use new tool, with the only justification > being we were forced to by the community (they may ask us to fork and not > use the tool) > 3) Adds stability risk. Mach-O objects are now being generated by different > code bases, and are not tested together like an Xcode release. > 4) Move the assembler syntax to a new, different syntax than the .S files > a) Compiler outputs .S syntax. > b) Debugger shows .S syntax. > c) Broader developer community does not use MASM/NASM syntax. > > The only upside I can see for moving to NASM would be if the code venders > deliver was coded and validated in NASM. So the XCODE targets will > probably switch over to requiring NASM years after the GCC targets. That > is why we need to split off XCODE. As a separate note, at the moment I have UEFI OS loader app which requires some assembly code. Yes, I know: I shouldn't do that. I would prefer not to, but I had to. There's just a couple of files and they're small, and everything worked out very well by the time I was done, so don't judge me. Anyway, I used GNU EFI as the basis for the app, so I originally wrote the assembly code in GNU assembler syntax. But I wanted people to be able to use the EDK to compile the app as well, so I made the code portable and provided a script to bundle up all the application source with a set of EDK build spec files into a ZIP file which could be unpacked in the EDK build environment and compiled there. Since I wanted people to be able to build on Windows (or in fact any of the supported EDK host platforms), I created MASM versions of the assembly code too. If EDK switches to using NASM, doesn't that mean I have to convert my application's assembly code to NASM too? I hope not, because maintaining two versions of the assembly code is work enough. > Thanks, > > Andrew Fish [...] -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Member of Technical Staff, wp...@windriver.com | Master of Unix-Fu - Wind River Systems ============================================================================= "I put a dollar in a change machine. Nothing changed." - George Carlin ============================================================================= ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
