On Tue, May 28, 2013 at 11:43 AM, Olivier Martin <olivier.mar...@arm.com> wrote: > Thanks for your useful comment. > > I looked which flags were used on x86 architectures to generate the PE/COFF > images with the GCC toolchain. And it seems that even if the comments in > tools_def says "This configuration is used to compile under Linux to produce > PE/COFF binaries using GCC 4.x", the GNU linker actually builds ELF image: > *_GCC44_IA32_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_FLAGS) -m > elf_i386 --oformat=elf32-i386 > *_GCC44_X64_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_FLAGS) > -melf_x86_64 --oformat=elf64-x86-64 > > From my understanding, it should use --oformat=(pei-i386|pei-x86-64) instead > to directly generate PE/COFF binaries. But I might have missed something.
Yes, GCC4* toolchains build ELF images, but GenFw converts them to PE/COFF. So, the final result is PE/COFF. I thought the ELF in "ELFGCC" referred to that ELF images would sometimes be produced by the toolchain. I think the Sec unix executable image was built directly with ELFGCC for UnixPkg. > Anyway, I am not sure GCC for ARM architectures supports PE/COFF (I guess > that would 'only' required to add the PE/COFF relocation symbols). But if > ELFGCC is deprecated for IA32/X64 usage and ARM GCC only supports ELF > output, do you see any issue to re-use ELFGCC as a cross-toolchain ? I don't think UEFI supports ELF images for any architecture. For that reason, I don't think a toolchain named "*ELF*" is a good idea. Maybe GCCCROSS is a better name? We've found that various versions of GCC require slightly different flags. Thus, GCC44-GCC47... -Jordan >> -----Original Message----- >> From: Jordan Justen [mailto:jljus...@gmail.com] >> Sent: 28 May 2013 19:07 >> To: Olivier Martin >> Cc: edk2-buildtools-de...@lists.sourceforge.net; edk2- >> de...@lists.sourceforge.net >> Subject: Re: [edk2-buildtools] [PATCH] BaseTools: Add support for a >> CROSS_COMPILE ELFGCC >> >> On Tue, May 28, 2013 at 10:30 AM, Olivier Martin >> <olivier.mar...@arm.com> wrote: >> > Any feedback on this change? Or is everyone happy by this >> CROSS_COMPILE >> > ELFGCC support? >> >> I think ELFGCC was pretty much deprecated for IA32/X64 usage. It was >> used only for UnixPkg. EmulatorPkg does not rely on ELFGCC, and >> therefore ELFGCC really has no relevant uses that I know of. >> >> I think ELFGCC was a good name for this toolchain, because it built >> ELF images for UnixPkg. But, I don't think ELFGCC is a good name for a >> toolchain that actually supports UEFI images, since they will be >> PE/COFF images. >> >> -Jordan >> >> > Again, this change should avoid duplication and bring flexibility for >> the >> > GCC toolchain in tools_def file. >> > >> > >> > >> > >> > >> > From: Olivier Martin [mailto:olivier.mar...@arm.com] >> > Sent: 10 May 2013 19:01 >> > To: edk2-buildtools-de...@lists.sourceforge.net >> > Cc: 'edk2-devel@lists.sourceforge.net' >> > Subject: [PATCH] BaseTools: Add support for a CROSS_COMPILE ELFGCC >> > >> > >> > >> > Dear BaseTools Maintainers, >> > >> > >> > >> > Please find the attached path that converts the current ELFGCC >> toolchain >> > into a toolchain that support cross toolchain (using the environment >> > variable CROSS_COMPILE). >> > >> > The way to call the toolchain for IA32 and X64 has not changed. >> > >> > >> > >> > For ARM, you would do something similar to (similar to build a Linux >> > kernel): >> > >> > CROSS_COMPILE=arm-linux-gnueabi- build -a ARM -p >> > MdeModulePkg/MdeModulePkg.dsc -t ELFGCC >> > >> > >> > >> > My plan after this patch is approved is to remove ARMGCC and >> ARMLINUXGCC >> > support from tools_def to only keep ELFGCC. >> > >> > >> > >> > Another benefit of this patch is that it cleans the IA32 and X64 and >> IPF >> > support in ELFGCC to share common flags. >> > >> > >> > >> > I also built MdeModulePkg/MdeModulePkg.dsc for IA32, X64 and ARM to >> confirm >> > these changes did not break the builds. MdeModulePkg.dsc build was >> broken >> > for X64 and this change does not fix it neither: >> > >> > ---- >> > >> > "/usr/bin/ld" -o >> > /tmp/tianocore- >> elfgcc/Build/MdeModule/DEBUG_ELFGCC/X64/MdeModulePkg/Application/HelloW >> orld/HelloWorld/DEBUG/HelloWorld.dll >> > -nostdlib --shared --entry _ModuleEntryPoint -u _ModuleEntryPoint - >> Map >> > /tmp/tianocore- >> elfgcc/Build/MdeModule/DEBUG_ELFGCC/X64/MdeModulePkg/Application/HelloW >> orld/HelloWorld/DEBUG/HelloWorld.map >> > -\( >> > @/tmp/tianocore- >> elfgcc/Build/MdeModule/DEBUG_ELFGCC/X64/MdeModulePkg/Application/HelloW >> orld/HelloWorld/OUTPUT/static_library_files.lst >> > -\) >> > >> > /usr/bin/ld: >> > /tmp/tianocore- >> elfgcc/Build/MdeModule/DEBUG_ELFGCC/X64/MdeModulePkg/Application/HelloW >> orld/HelloWorld/OUTPUT/HelloWorld.lib(AutoGen.obj): >> > relocation R_X86_64_32 against `.rodata.str1.1' can not be used when >> making >> > a shared object; recompile with -fPIC >> > >> > /tmp/tianocore- >> elfgcc/Build/MdeModule/DEBUG_ELFGCC/X64/MdeModulePkg/Application/HelloW >> orld/HelloWorld/OUTPUT/HelloWorld.lib: >> > could not read symbols: Bad value >> > >> > ---- >> > >> > >> > >> > I also made an analysis of the compilation flags before and after >> applying >> > the patch. Additional cleaning can be made. >> > >> > >> > >> > # C Compiler >> > >> > >> > >> > Common arguments: >> > >> > -o >> > /tmp/tianocore- >> elfgcc/Build/MdeModule/DEBUG_$(TOOLCHAIN)/$(ARHC)/MdePkg/Library/BaseDe >> bugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib/OUTPUT/./BaseDebugPri >> ntErrorLevelLib.obj >> > -I/tmp/tianocore-elfgcc/MdePkg/Library/BaseDebugPrintErrorLevelLib >> > -I/tmp/tianocore-elfgcc/MdePkg/Include/$(ARCH) >> > -I/tmp/tianocore- >> elfgcc/Build/MdeModule/DEBUG_ELFGCC/$(ARCH)/MdePkg/Library/BaseDebugPri >> ntErrorLevelLib/BaseDebugPrintErrorLevelLib/DEBUG >> > -I/tmp/tianocore-elfgcc/MdePkg/Include -I/tmp/tianocore-elfgcc/MdePkg >> > /tmp/tianocore- >> elfgcc/MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLe >> velLib.c >> > >> > -c -g -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-missing- >> braces >> > -Wno-array-bounds >> > >> > >> > >> > IA32: >> > >> > before: '-Werror -Wno-missing-braces -Wno-array-bounds' were not >> present >> > >> > before/after common: -m32 -malign-double -include >> > /tmp/tianocore- >> elfgcc/Build/MdeModule/DEBUG_ELFGCC/IA32/MdePkg/Library/BaseDebugPrintE >> rrorLevelLib/BaseDebugPrintErrorLevelLib/DEBUG/AutoGen.h >> > -DSTRING_ARRAY_NAME=BaseDebugPrintErrorLevelLibStrings >> > >> > after adds "-Os -include AutoGen.h -freorder-blocks >> > -freorder-blocks-and-partition -O2 -mno-stack-arg-probe -O0" >> > >> > >> > >> > X64: >> > >> > before/after common: -Os -Wno-address -include AutoGen.h -D_EFI_P64 >> > >> > before: '-g' was not present >> > >> > after adds: -mno-red-zone -mno-stack-arg-probe -O0 >> > >> > >> > >> > ARM >> > >> > before/after common: -mthumb -march=armv7-a -Wno-address -Os -include >> > AutoGen.h -mword-relocations -mlittle-endian -mabi=aapcs -mapcs >> > -fno-short-enums -save-temps -fsigned-char -ffunction-sections >> > -fdata-sections -fomit-frame-pointer -O0 >> > >> > after adds '-fno-stack-protector' >> > >> > >> > >> > # ASM Compiler >> > >> > >> > >> > Common arguments: >> > >> > -c -x assembler -imacros >> > /tmp/tianocore- >> elfgcc/Build/MdeModule/DEBUG_ELFGCC/IA32/MdePkg/Library/BaseLib/BaseLib >> /DEBUG/AutoGen.h >> > -I/tmp/tianocore-elfgcc/MdePkg/Library/BaseLib/$(ARCH) >> > -I/tmp/tianocore-elfgcc/MdePkg/Library/BaseLib >> > -I/tmp/tianocore- >> elfgcc/Build/MdeModule/DEBUG_$(TOOLCHAIN)/$(ARCH)/MdePkg/Library/BaseLi >> b/BaseLib/DEBUG >> > -I/tmp/tianocore-elfgcc/MdePkg/Include/$(ARCH) >> > >> > >> > >> > after: add '-g' (Generate debugging information for each assembler >> source >> > line using whichever debug format is preferred by the target) >> > >> > >> > >> > IA32: before/after: Same command line >> > >> > X64: before/after: Same command line >> > >> > >> > >> > ARM >> > >> > - before: '-I/tmp/tianocore-elfgcc/MdePkg/Include >> > -I/tmp/tianocore-elfgcc/MdePkg ' was not present >> > >> > - before/after: Similar command line expect 'before' was using >> > "arm-linux-gnueabi-as" while 'after' uses "arm-linux-gnueabi-gcc -c - >> x >> > assembler" >> > >> > >> > >> > # SLINK >> > >> > >> > >> > IA32: before/after: Same command line >> > >> > X64: before/after: Same command line >> > >> > ARM: before/after: Same command line >> > >> > >> > >> > # DLINK: >> > >> > >> > >> > IA32: before/after: Same command line >> > >> > X64: before/after: Same command line >> > >> > ARM: before/after: Same command line >> > >> > >> > >> > >> > >> > Thanks, >> > >> > Olivier >> > >> > >> > --------------------------------------------------------------------- >> --------- >> > Try New Relic Now & We'll Send You this Cool Shirt >> > New Relic is the only SaaS-based application performance monitoring >> service >> > that delivers powerful full stack analytics. Optimize and monitor >> your >> > browser, app, & servers with just a few lines of code. Try New Relic >> > and get this awesome Nerd Life shirt! >> http://p.sf.net/sfu/newrelic_d2d_may >> > _______________________________________________ >> > edk2-buildtools-devel mailing list >> > edk2-buildtools-de...@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel >> > > > > > ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
