On 07/14/16 19:16, Kinney, Michael D wrote:
> Laszlo,
> 
> It may be possible to update NASM source to be compatible with both older and 
> latest
> version of NASM.

I claim that it's not possible in this case, as long as we'd like to
avoid DBs and other coding tricks (i.e., as long as we'd like to write
what we mean). Of course if I'm proved wrong, I'll welcome it :)

> We would have to evaluate the current build breaks to see if that is
> possible or not.

It should be possible to reproduce in Windows build environments as
well, by removing the currently installed NASM package, and installing
the one from <http://www.nasm.us/pub/nasm/releasebuilds/2.07/win32/>.

> For VS20xx tool chains, I prefer to specify the min at 2.12.01.

I will update my patch to state this.

> I think support for 
> source level debug is a requirement for actively supported tool chains.  

It may be a requirement for actively supported *non-GCCxx* toolchains.
It's definitely not satisfied for GCCxx toolchains. (I'd love if it were!)

I will update my patch to say that 2.10 is required for the GCC
toolchain family, and 2.12.01 is required for all other tooolchain families.

Thanks!
Laszlo


>> -----Original Message-----
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Laszlo Ersek
>> Sent: Thursday, July 14, 2016 9:19 AM
>> To: Kinney, Michael D <michael.d.kin...@intel.com>; Michael Zimmermann
>> <sigmaepsilo...@gmail.com>; Gao, Liming <liming....@intel.com>
>> Cc: Justen, Jordan L <jordan.l.jus...@intel.com>; edk2-devel-01 <edk2-
>> de...@ml01.01.org>
>> Subject: Re: [edk2] minimum NASM version
>>
>> On 07/14/16 17:47, Kinney, Michael D wrote:
>>> Laszlo,
>>>
>>> We may have to specify a different min version based on the toolchain used.
>>>
>>> For VS20xx toolchains, we must have 2.12.01 as the minimum to support 
>>> source level
>> debug.
>>>
>>> If GCCxx toolchains are compatible with NASM 2.07, then I see no reason to 
>>> not
>> document it that way.
>>
>> The problem with NASM 2.07 is not compatibility with any GCCxx toolchain.
>>
>> The problem with NASM 2.07 is that it is unable to build NASM source code 
>> already
>> committed to the tree.
>>
>> This is the patch I currently have:
>>
>>> diff --git a/BaseTools/Conf/tools_def.template 
>>> b/BaseTools/Conf/tools_def.template
>>> index 2065fa34998f..fca4319b7cfa 100644
>>> --- a/BaseTools/Conf/tools_def.template
>>> +++ b/BaseTools/Conf/tools_def.template
>>> @@ -708,7 +708,10 @@ DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program
>> Files/CodeSourcery/Sourcery G
>>>  #
>>>  # Other Supported Tools
>>>  # =====================
>>> -#   NASM 2.07 or later                 http://www.nasm.us/
>>> +#   NASM -- http://www.nasm.us/
>>> +#   - NASM 2.10 or later for assembling *.nasm and *.nasmb source files
>>> +#   - NASM 2.12.01 or later if, in addition, source level debug information
>>> +#     should be produced for the MSFT toolchain family
>>>  #
>>>  
>>> ####################################################################################
>>>  
>>> ####################################################################################
>>
>> I presume NASM 2.10 will work just fine with VS20xx toolchains, as long as 
>> one is not
>> interested in source level debugging. Is that correct?
>>
>> Thanks
>> Laszlo
>>
>>
>>>> -----Original Message-----
>>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>>>> Laszlo Ersek
>>>> Sent: Thursday, July 14, 2016 8:25 AM
>>>> To: Michael Zimmermann <sigmaepsilo...@gmail.com>; Gao, Liming
>> <liming....@intel.com>
>>>> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Justen, Jordan L
>>>> <jordan.l.jus...@intel.com>; edk2-devel-01 <edk2-de...@ml01.01.org>
>>>> Subject: Re: [edk2] minimum NASM version
>>>>
>>>> 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
>>
>> _______________________________________________
>> edk2-devel mailing list
>> 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

Reply via email to