On 07/14/16 16:51, Michael Zimmermann wrote: > Hi, > > if it would be very important to support that old version of NASM you > could just write "raw" assembler by putting the needed instructions as > word's within the executable code.
Edk2 has prided itself on supporting several versions of several toolchains. For the MSFT toolchain family, this seems to go back to VS2003. For the GCC toolchain family, it goes back to GCC44. NASM 2.07 is exactly from the era that GCC44 belongs to. If we bump the NASM requirement to 2.10, that would actually suggest to drop support for GCC toolchains up to and including GCC46. The era to which NASM 2.10 belongs also provides GCC47, so on a GNU/Linux distro where you find NASM 2.10, you should also find GCC47. Now, if we raise the NASM requirement to 2.10, but don't drop GCC44, GCC45, and GCC46, that might render these three GCC toolchains "un-utilizable" in practice, but that's not a problem in fact. The reason is that all GNU/Linux distros that are still supported will offer you GCC47 + NASM 2.10 (or later), so you won't *need* GCC44, GCC45, GCC46. We can remove them any time we like. (Actually, I'm lying a bit: dropping support for NASM 2.07 and GCC44 renders RHEL-6 (still alive) unsupported as an edk2 build host, but that's just a reality check: the NASM source code in the tree won't build on RHEL-6 *anyway*.) Bumping the requirement from NASM 2.10 to something higher would be very bad. For example, RHEL-7 and Debian oldstable (both alive) would be rendered unsupported as build systems. This would be akin to dropping GCC47 and GCC48 -- catastrophic. There's no reason for doing this, given that NASM 2.10 can build the NASM assembly code in the tree just fine (without open-coded DBs). > changing the min requirement seems more proper though :) I'd like to raise the requirement to 2.10, because that is both justified by the source code in the tree, and satisfied by most GNU/Linux distros that are still alive. I disgree with raising the requirement above 2.10. It wouldn't provide universally useful features, but render distros that are still alive (and fully capable of building edk2) unsupported as edk2 build platforms. Thanks Laszlo > On Thu, Jul 14, 2016 at 4:28 PM, Gao, Liming <liming....@intel.com > <mailto:liming....@intel.com>> wrote: > > Laszlo: > Sorry. I didn't mention my version. I use 2.12.01 to verify all > changes. In 2.12, it adds support of Codeview version 8 (cv8) debug > format for win32 and win64 formats in the COFF backend. We need this > feature to get cv8 debug. But, this version will report the error > message: nasm: fatal: assertion !"relocation for unregistered > symbol" failed at output/codeview.c:420. So, I suggest to update > comments to NASM 2.12.01. > > Thanks > Liming > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org > <mailto:edk2-devel-boun...@lists.01.org>] On Behalf Of Laszlo Ersek > Sent: Thursday, July 14, 2016 8:04 PM > To: Gao, Liming <liming....@intel.com > <mailto:liming....@intel.com>>; Justen, Jordan L > <jordan.l.jus...@intel.com <mailto:jordan.l.jus...@intel.com>>; > Kinney, Michael D <michael.d.kin...@intel.com > <mailto:michael.d.kin...@intel.com>> > Cc: edk2-devel-01 <edk2-de...@ml01.01.org > <mailto:edk2-de...@ml01.01.org>> > Subject: Re: [edk2] minimum NASM version > > On 07/14/16 13:19, Laszlo Ersek wrote: > > > It seems that before NASM 2.10, there's simply no way to access > segment > > registers in 64-bit mode. I propose that we upgrade the following > > comment in BaseTools: > > > >> diff --git a/BaseTools/Conf/tools_def.template > b/BaseTools/Conf/tools_def.template > >> index 2065fa34998f..db61a37b6afd 100644 > >> --- a/BaseTools/Conf/tools_def.template > >> +++ b/BaseTools/Conf/tools_def.template > >> @@ -708,7 +708,7 @@ DEFINE SOURCERY_CYGWIN_TOOLS = > /cygdrive/c/Program Files/CodeSourcery/Sourcery G > >> # > >> # Other Supported Tools > >> # ===================== > >> -# NASM 2.07 or later http://www.nasm.us/ > >> +# NASM 2.10 or later http://www.nasm.us/ > >> # > >> > > #################################################################################### > >> > > #################################################################################### > > > > plus wherever the minimum NASM version is documented on the Wiki. > > * In support of the above suggestion: in my Fedora 13 guest (set up for > GCC44 build testing), I could rebuild the following NASM package without > any problems, from the source RPM: > > nasm-2.10.09-1.fc21 > http://koji.fedoraproject.org/koji/buildinfo?buildID=463939 > > With this package installed, the build completed fine. > > * Also in support: the "oldstable" Debian release (code name "wheezy") > ships nasm 2.10 as well: > > https://packages.debian.org/search?keywords=nasm > > Thanks > Laszlo > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > <mailto:edk2-devel@lists.01.org><mailto:edk2-devel@lists.01.org > <mailto:edk2-devel@lists.01.org>> > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> > https://lists.01.org/mailman/listinfo/edk2-devel > > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
