> On Nov 6, 2014, at 1:42 AM, Andrew Fish <[email protected]> wrote: > >> >> On Nov 6, 2014, at 12:26 AM, Jordan Justen <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 2014-11-05 20:29:46, Andrew Fish wrote: >>> >>> On Nov 5, 2014, at 7:51 PM, Jordan Justen <[email protected] >>> <mailto:[email protected]>> >>> wrote: >>> >>> On 2014-11-05 19:19:26, Andrew Fish wrote: >>> On Nov 5, 2014, at 6:47 PM, Gao, Liming <[email protected] >>> <mailto:[email protected]>> >>> wrote: >>> >>> Jordan: >>> This patch updates module INF with .nasm only, and remove the >>> original .asm and .S. Right? >>> >>> After apply this patch, all developers are required to install >>> nasm >>> compiler. >>> >>> We require the option of NOT using nasm with the XCODE target. >>> >>> MdePkg has required NASM for Thunk16 IA32 and X64 (except MSFT/INTEL >>> based toolchains) for 2 months now. (Since Sept 1st.) >>> >>> That hasn't been an issue? >>> >>> Because it is is easy to change a single file in an INF file to make it work >>> without NASM. >> >> Does that mean that these trees are separate from EDK II, or UDK? So, >> maybe one solution would be a patch file or git branch that contains >> the .S files? >> >> Which packages would that be required for? >> > > I think you have it backwards. Adding NASM to UDK is breaking it for us. So > the UDK release need to support .S files. > >>> Folks are probably not doing production builds on the edk2 TOT, the >>> production builds are being done on the UDK2014. >> >> Ah, so UDK2014 releases are more important? Meaning maybe the patch >> file could be produced only for those releases? >> > > The UDK2014 should NOT move to NASM and still support .S files. > > When is the Intel reference code going to be coded in NASM? I’d be willing to > discuss dropping .S files from the UDK when all the Intel reference code is > coded in NASM and not MASM. > >>> In our world we don’t control the build servers, we don’t install >>> the tools on the build server, and if we try to check in a binary it >>> gets rejected. Not to mention I would rather walk down the hall and >>> talk to the tools developers than fly to Europe if I have an issue. >> >> Is NASM just plain incompatible with XCODE? >> > > We prefer to use the tools we make and Xcode contains an assembler, so we > would like to use that. I can walk into the office and talk to the tools team > face to face, I’d need to fly to Europe to talk the NASM guys. > It is safer to use a complete tools set than mix and match tools. For example > with NASM we now have 2 different code bases that generate Mach-O objects > that need to get linked together. > >> If not, I guess one other possible solution would be to pull NASM into >> BaseTools. It is an idea that's been mentioned, but is (obviously) not >> a first choice. >> >>> So the change to NASM buys us nothing, introduces risk, causes a lot >>> of extra work. >>> >>> I picked a random edk2/MdePkg .S file and the code has not been >>> updated since 2009, and the file not modified since 2010. What >>> problem are we solving again? >> >> Some benefits of NASM: >> >> * A single cross platform assembly file for either IA32 or X64 >> > > Changing every assembly file is some what risky. > >> * Often both MASM and GNU assembly end up requiring 'db' gymnastics >> that produces unreadable/unmaintainable code. (Did you see the >> Thunk16.asm/.S freak show?) >> > > Yes that was bad, but that code will likely not change for the next 10 years. > >> * Many developers only work on Windows, and therefore never bother to >> code a .S file. Most commonly, this results in code modules that >> only builds on Windows. >> > > Yes and a lot of them work for Intel. Why don’t you fix that problem 1st. > >> * In some rare cases an effort is made to port to a .S file. This >> often results in code that is really ugly, non-functional, >> not-functional for all toolchains, or functional somewhat by luck. >> See again: Thunk16 >> > > We have been using .S files for a while and we don’t generally have issues. > >> * One sore spot for MASM vs. GNU assembly has been the 'VTF' file, >> which for many platforms has source code that looks like >> IntelFspPkg/FspSecCore/Ia32/ResetVec.asm16. We finally have a cross >> platform version at UefiCpuPkg/ResetVector/FixupVtf/Vtf.nasmb >> > > We don’t have any issue generating this code today with Xcode. It is mostly a > copy paste from project to project. > > There is not a lot of “New” 16-bit code getting written these days. It is all > the same code sequences forced on us by Intel. > >> * Related to .asm16, it depends on getting a 16-bit version of MASM >> that seems increasingly difficult to obtain, and seemingly is not >> actively developed. (Or, is it the 16-bit linker... ??) >> > > Not an issue for us, we support .S16 with Xcode. > >> * NASM is also: >> * actively developed >> * easy to build >> * readily available pre-built for most platforms >> * BSD licensed >> > > Xcode is also actively developed. > > The point of MdePkg BaseLib was to remove the need to write assembler. There > is some other code along the way like SEC, interrupt handlers, INIT SIPI > SIPI, etc., but given this all Intel Architecture stuff so it does not really > tend to change a lot. > > Thanks, > > Andrew Fish >
The original is held up since it is too big…. How does dead stripping work with NASM? With Xcode assembler we have to add an assembly directive, .subsections_via_symbols, so the linker knew it was OK to dead strip (and prefix intermediate labels with L). It looks like the Thunk16.nasm code ends up in every module that links the BaseLib with the XCODE5 target. This was not the case with .S files that contain ASM_FUNCTION_REMOVE_IF_UNREFERENCED which gets mapped to .subsections_via_symbols on Xcode builds. That is a big code size hit it moving to NASM! Thanks, Andrew Fish PS Looks like I need to patch some missing ASM_FUNCTION_REMOVE_IF_UNREFERENCED in the MdePkg Library .S files.
------------------------------------------------------------------------------
_______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
