> On Jun 9, 2015, at 10:00 AM, Jordan Justen <jordan.l.jus...@intel.com> wrote: > > On 2015-06-09 02:38:02, Gao, Liming wrote: >> Jordan: >> Yes. I agree .bin is better postfix for .nasmb. After we fully >> migrate .asm16 to .nasmb, I will update our reference platform to >> use .bin in their FDF Ffs Rules. > > This sounds like an ok plan. > > But, then we will have to leave the build-rule copy to a .com file, > right? Because now we will have to be backward-compatible with the > fact that .nasmb was making .com files for a few months. Sigh... :) >
Who is consuming the .com file? The [Masm16-Code-File] rule in https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/Conf/build_rule.template <https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/Conf/build_rule.template> does an ASMLINK/DLINK/otool depending on the tool chain. While the [Nasm-to-Binary-Code-File] just makes a binary. I assume this means the nasmb binary is the correct form. Ah so now I see https://svn.code.sf.net/p/edk2/code/trunk/edk2/Vlv2TbltDevicePkg/ <https://svn.code.sf.net/p/edk2/code/trunk/edk2/Vlv2TbltDevicePkg/> [Rule.Common.SEC] FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED { PE32 PE32 Align = 8 $(INF_OUTPUT)/$(MODULE_NAME).efi RAW BIN Align = 16 |.com } [Rule.Common.SEC.BINARY] FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED { PE32 PE32 Align = 8 |.efi RAW BIN Align = 16 |.com } So the build_rule.template file can be per compiler but the rules in the FDF file are generic. So this is the reason that is hard to change. If we changed the build_rule.template file then the rules in platform FDF files would all break. So this ends up being a compatibility issue with trees based on the edk2. Thanks, Andrew Fish > Anyway, my suggestion was to make new .inf files for the nasm > versions, and convert the platforms to the new .inf and update their > .fdf files when changing to the nasm .inf. > > Then, in the end you can delete the masm .inf files and .asm16 files. > > -Jordan > >> -----Original Message----- >> From: Justen, Jordan L >> Sent: Tuesday, June 09, 2015 3:12 PM >> To: Gao, Liming; edk2-devel@lists.sourceforge.net >> Subject: RE: [edk2] [Patch] BaseTools: Update nasmb build rule >> >> On 2015-06-08 18:31:30, Gao, Liming wrote: >>> Jordan: >>> I don't get any feedback from others. You also say I can go ahead. >>> So, I add this change. >> >> Ok. You are right. It is true that I said: "I don't like the idea of >> creating the .com for .nasmb sources, but if you insist that it is required, >> then you can go ahead." >> >> So, I guess you went ahead. >> >> Can you at least agree that the use of the .com extension is confusing in >> this case, since .com files are 16-bit DOS executables? I think the only >> reason they appeared in EDK/EDK II is because masm16 would only output a >> .com file. >> >> I don't think we need to make everything backward compatible. This is a new >> tool without the legacy masm baggage, so do we really need to go out of our >> way to bring the masm baggage along? >> >> Really, wouldn't it be reasonable for a platform to make a 1-line change to >> their .fdf file if for no other reason than to make it obvious that a big >> change just happened to their SEC phase? >> >> This project goes *way* out of it's way to try to be backward compatible. In >> my opinion, often too far. >> >> Ok. Rant complete. Thanks for your time, :) >> >> -Jordan >> >>> I add this support for compatibility. I want to update our core >>> module to use .nasmb, and platform can directly use the updated >>> core module without changes. Now, our most platforms use .com >>> postfix in their platform FDF Ffs Rule. With this patch, after we >>> update more core modules to use .nasmb instead .asm16, it will not >>> impact platforms. >>> >>> Thanks >>> Liming >>> -----Original Message----- >>> From: Justen, Jordan L >>> Sent: Tuesday, June 9, 2015 12:56 AM >>> To: Gao, Liming; edk2-devel@lists.sourceforge.net >>> Subject: RE: [edk2] [Patch] BaseTools: Update nasmb build rule >>> >>> On 2014-11-21 10:16:47, Jordan Justen wrote: >>>> On 2014-11-20 22:12:42, Gao, Liming wrote: >>>>> Jordan: >>>>> NASMB is replacement of ASM16. >>>> >>>> I see .nasmb as an alternative, but not a replacement. (.asm16 is >>>> still supported by EDK II.) >>>> >>>> I do hope that long term it replaces all uses of .asm16 though. :) >>>> >>>>> Now, ASM16 has been used in the >>>>> different modules. When the module owners do this conversion, they >>>>> expect it is compatible and doesn't impact platform, because >>>>> module owner can't predict how many platform will be impacted. So, >>>>> I think the compatibility is the important point to persuade the >>>>> module owners to do this conversion. >>>> >>>> I would rather see .bin be used in this case, because it makes more >>>> sense than .com. I guess .com was used because it was the output >>>> from link16? But, .com files are known as old dos based executables. >>>> It is a confusing use of the extension. >>> >>> I see you went ahead and committed this without further discussion. >>> >>> I also see that you converted an internal platform's fdf from being >>> able to accept either .bin or .com to only accept .com. So, apparently >>> you have real preference for using .com rather than .bin. >>> >>> Can you explain why you think .com makes better sense than .bin in >>> this context? >>> >>> http://en.wikipedia.org/wiki/COM_file >>> >>> -Jordan >>> >>>> If we copy the file like in your patch, then few platforms will >>>> actually change from using .com to .bin, but I think it would be an >>>> improvement for them to convert to using the .bin extension. >>>> >>>> Maybe another idea is to leave the .asm16 .inf in place, and create >>>> a new .inf with the .nasmb source. Then the platform will have to >>>> change both the .dsc and .fdf to make use of NASM. This will also >>>> leave the platform with the option to continue using MASM16/LINK16. >>>> >>>> I don't like the idea of creating the .com for .nasmb sources, but >>>> if you insist that it is required, then you can go ahead. I will not >>>> give my r-b for the change though. :) >>>> >>>> -Jordan >>>> >>>>> -----Original Message----- >>>>> From: Justen, Jordan L >>>>> Sent: Friday, November 21, 2014 12:58 PM >>>>> To: edk2-devel@lists.sourceforge.net; Gao, Liming >>>>> Subject: Re: [edk2] [Patch] BaseTools: Update nasmb build rule >>>>> >>>>> On 2014-11-18 23:49:45, Gao, Liming wrote: >>>>>> Nasmb can replace ASM16. Now, ASM16 output file is *.com. To be >>>>>> compatible with it, update nasmb build rule to output *.com file also. >>>>>> >>>>>> ASM16 output file is used by Platform FDF Rule section. With >>>>>> this patch, Platform FDF file will not be impacted after asm16 >>>>>> file is converted to nasmb file. >>>>> >>>>> Liming, >>>>> >>>>> I don't think we need this change. With a small change to the .fdf, .bin >>>>> can work as easily as .com. >>>>> >>>>> I think .com was a bad extension for this file, even when >>>>> masm16/link16 was being used. Maybe we should have copied from .com to >>>>> .bin before. >>>>> >>>>> -Jordan >>>>> >>>>>> Contributed-under: TianoCore Contribution Agreement 1.0 >>>>>> Signed-off-by: Liming Gao <liming....@intel.com> >>>>>> >>>>>> --- >>>>>> >>>>>> Index: build_rule.template >>>>>> >>>>>> ================================================================ >>>>>> == >>>>>> = >>>>>> >>>>>> --- build_rule.template (revision 16400) >>>>>> >>>>>> +++ build_rule.template (working copy) >>>>>> >>>>>> @@ -491,8 +491,8 @@ >>>>>> >>>>>> "$(PP)" $(PP_FLAGS) $(INC) ${src} > >>>>>> ${d_path}(+)${s_base}.i >>>>>> >>>>>> Trim --source-code --convert-hex -o >>>>>> ${d_path}(+)${s_base}.iii $ {d_path}(+)${s_base}.i >>>>>> >>>>>> "$(NASM)" -I${s_path}(+) -l ${d_path}(+)${s_base}.lst >>>>>> $(NASMB_FLAGS) -o $dst ${d_path}(+)${s_base}.iii >>>>>> >>>>>> + $(CP) ${dst} $(OUTPUT_DIR)(+)${s_base}.com >>>>>> >>>>>> - >>>>>> >>>>>> [Microcode-File.USER_DEFINED, Microcode-File.Microcode] >>>>>> >>>>>> <InputFile> >>>>>> >>>>>> ?.txt, ?.TXT, ?.Txt, ?.mut, ?.inc >>>>>> >>>>>> --- >>>>>> >>>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> Liming >>>>>> >>>>>> >>>>>> > > ------------------------------------------------------------------------------ > _______________________________________________ > 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
