Re: [Linaro-uefi] Compiling CPP files ARM64

-- Ard. > On Tue, Feb 2, 2016 at 4:40 PM, Ard Biesheuvel ard.biesheuvel@linaro.org > wrote: >> >> It looks like you are using the wrong compiler. You should use GCC48 >> or GCC49 instead. >> >> >> On 2 February 2016 at 12:08, Ravikanth MVR ravikanth.mvr@broadcom.com >> wrote: >> > Thanks Ard!I followed the steps and I could find out that NO standard >> > library was included.Below is the list of libraries that were getting >> > included. >> > >> > UefiApplicationEntryPoint.lib(ApplicationEntryPoint.obj) >> > HelloWorld.lib(AutoGen.obj) >> > UefiDebugLibStdErr.lib(DebugLib.obj) >> > UefiBootServicesTableLib.lib(UefiBootServicesTableLib.obj) >> > UefiRuntimeServicesTableLib.lib(UefiRuntimeServicesTableLib.obj) >> > UefiLib.lib(UefiLib.obj) >> > BaseDebugPrintErrorLevelLib.lib(BaseDebugPrintErrorLevelLib.obj) >> > BasePrintLib.lib(PrintLib.obj) >> > BasePrintLib.lib(PrintLibInternal.obj) >> > BaseLib.lib(DivU64x32Remainder.obj) >> > BaseLib.lib(CpuDeadLoop.obj) >> > BaseLib.lib(String.obj) >> > BaseLib.lib(Unaligned.obj) >> > BaseLib.lib(Math64.obj) >> > >> > I have included .map file as well with this mail. >> > >> > Thanks. >> > >> > On Mon, Feb 1, 2016 at 1:24 PM, Ard Biesheuvel >> > ard.biesheuvel@linaro.org >> > wrote: >> >> >> >> On 1 February 2016 at 08:36, M.V.R. Ravikanth >> >> ravikanth.mvr@avagotech.com wrote: >> >> > Ard, >> >> > >> >> > I understand that we have to implement alternative C++ runtime API >> >> > which >> >> > maps to new and delete in EDK2 i.e.,AllocatePool and FreePool. >> >> > >> >> > I did implement alternative new and delete API's,which uses >> >> > AllocatePool >> >> > and >> >> > FreePool,for OUR code and most of the relocation errors had gone.BUT >> >> > when >> >> > the CPP program(HelloWorld) under compilation doesn't even call the >> >> > C++ >> >> > runtime API's,why are we seeing these errors?-This is what I am >> >> > trying >> >> > to >> >> > understand. >> >> > >> >> >> >> If you add a -Map xxx.map option to the linker command, you will get a >> >> map file that tells you exactly which object was included in the link, >> >> and why (iow, which symbol dependency it satisfies) That way, you will >> >> be able to figure out which standard library is included, and for >> >> which reason. >> >> >> >> > Thanks. >> >> > ________________________________ >> >> > From: Ard Biesheuvel >> >> > Sent: ‎01-‎02-‎2016 12:31 >> >> > To: M.V.R. Ravikanth >> >> > >> >> > Cc: Leif Lindholm; Daniel Samuelraj; Jianning Wang; Linaro UEFI >> >> > Mailman >> >> > List; Sadananda Murthy; Unnikrishnan P S >> >> > Subject: Re: [Linaro-uefi] Compiling CPP files ARM64 >> >> > >> >> > On 1 February 2016 at 07:51, M.V.R. Ravikanth >> >> > ravikanth.mvr@avagotech.com wrote: >> >> >> Ard, >> >> >> I would try to explain here, >> >> >> >> >> >> 1.Till now we have been compiling CPP programs in UDK with >> >> >> VS2005/VS2008 >> >> >> as >> >> >> toolchain and it worked well. >> >> >> >> >> >> 2.Now,we have a requirement to support AARCH64 architecture with >> >> >> ARMGCC >> >> >> as >> >> >> the toolchain.But when we tried to compile our CPP code/Sample >> >> >> HelloWorld >> >> >> application(HelloWorld.c is renamed to HelloWorld.cpp) with ARMGCC >> >> >> as >> >> >> toolchain,we were seeing relocation errors such as 0x105. >> >> >> >> >> >> 3.As advised by you,we tried compiling a sample HelloWorld CPP >> >> >> program >> >> >> under >> >> >> EDK2 and still we are seeing the same relocation errors. >> >> >> >> >> >> Questions: >> >> >> >> >> >> 1.If EDK2 doesn't support CPP code,what should we do to resolve the >> >> >> relocation errors we are observing? >> >> >> >> >> >> Please correct me,if I have missed something. >> >> >> >> >> > >> >> > The relocation errors are a symptom of the fact that you are trying >> >> > to >> >> > link the Linux specific C++ runtime into your EDK2 binary. This is a >> >> > pointless exercise, since the Linux C++ runtime is fundamentally >> >> > incompatible with EDK2, So please, don't ask any more questions about >> >> > relocation errors, and focus on implementing an alternative C++ >> >> > runtime that maps calls to new() and delete() onto EDK2 APIs, i.e., >> >> > AllocatePool and FreePool. Note that you will still have problems >> >> > with >> >> > symbol decoration, since EDK2 header file don't have 'extern "C"' >> >> > qualifiers around C declarations. >> >> > >> >> > >> >> > >> >> >> ________________________________ >> >> >> From: Ard Biesheuvel >> >> >> Sent: ‎01-‎02-‎2016 11:59 >> >> >> To: Ravikanth MVR >> >> >> Cc: Leif Lindholm; Daniel Samuelraj; Jianning Wang; Linaro UEFI >> >> >> Mailman >> >> >> List; Sadananda Murthy; Unnikrishnan P S >> >> >> Subject: Re: [Linaro-uefi] Compiling CPP files ARM64 >> >> >> >> >> >> On 31 January 2016 at 20:16, Ravikanth MVR >> >> >> ravikanth.mvr@avagotech.com >> >> >> wrote: >> >> >>> +Unni. >> >> >>> >> >> >>> Ard, >> >> >>> I have done a native compilation with EDK2 and I am facing same >> >> >>> issues >> >> >>> as >> >> >>> I >> >> >>> did before.Below is the snapshot of the errors I received. >> >> >>> >> >> >> >> >> >> I have explained twice already why C++ under EDK2 is not going to >> >> >> work. What exactly were you expecting? >> >> >> -- >> >> >> Ard. >> >> >> >> >> >> >> >> >>> "GenFw" -e UEFI_APPLICATION -o >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> /home/edk2/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.efi >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> /home/edk2/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll >> >> >>> GenFw: ERROR 3000: Invalid >> >> >>> WriteSections64(): >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> /home/edk2/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll >> >> >>> unsupported ELF EM_AARCH64 relocation 0x105. >> >> >>> GenFw: ERROR 3000: Invalid >> >> >>> make: *** >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> [/home/edk2/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.efi] >> >> >>> Error 2 >> >> >>> WriteRelocations64(): >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> /home/edk2/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll >> >> >>> unsupported ELF EM_AARCH64 relocation 0x105. >> >> >>> >> >> >>> >> >> >>> build.py... >> >> >>> : error 7000: Failed to execute command >> >> >>> make --no-print-directory all >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> [/home/edk2/MyWorkSpace/Build/MdeModule/RELEASE_ARMGCC/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld] >> >> >>> >> >> >>> - Failed - >> >> >>> Build end time: 19:12:41, Jan.31 2016 >> >> >>> Build total time: 00:00:15 >> >> >>> >> >> >>> Thanks >> >> >>> Ravi >> >> >>> >> >> >>> On Wed, Jan 27, 2016 at 2:31 PM, Ard Biesheuvel >> >> >>> ard.biesheuvel@linaro.org >> >> >>> wrote: >> >> >>>> >> >> >>>> On 27 January 2016 at 09:51, Ravikanth MVR >> >> >>>> ravikanth.mvr@avagotech.com >> >> >>>> wrote: >> >> >>>> > Ard, >> >> >>>> > I was trying to compile and generate helloworld application via >> >> >>>> > EDK2.Under >> >> >>>> > the "MyWorkSpace\BaseTools\Bin" directory I did not find "Win32" >> >> >>>> > directory >> >> >>>> > which has GenFw utility.But the UDK package has Win32 directory. >> >> >>>> > >> >> >>>> > Could you let me know on how to build and EDK2 package in >> >> >>>> > Windows >> >> >>>> > or >> >> >>>> > else Am >> >> >>>> > I missing something here? >> >> >>>> > >> >> >>>> >> >> >>>> I haven't used Windows for software development work in 15 years, >> >> >>>> so >> >> >>>> I >> >> >>>> am really not the person you should be asking this. >> >> >>>> >> >> >>>> -- >> >> >>>> Ard. >> >> >>>> >> >> >>>> > On Thu, Jan 14, 2016 at 3:03 PM, Ravikanth MVR >> >> >>>> > ravikanth.mvr@avagotech.com >> >> >>>> > wrote: >> >> >>>> >> >> >> >>>> >> In UDK.I will try out on EDK2 and let you know the results. >> >> >>>> >> >> >> >>>> >> Thanks. >> >> >>>> >> >> >> >>>> >> On Thu, Jan 14, 2016 at 3:02 PM, Ard Biesheuvel >> >> >>>> >> ard.biesheuvel@linaro.org wrote: >> >> >>>> >>> >> >> >>>> >>> On 14 January 2016 at 10:28, Ravikanth MVR >> >> >>>> >>> ravikanth.mvr@avagotech.com >> >> >>>> >>> wrote: >> >> >>>> >>> > Ard, >> >> >>>> >>> > >> >> >>>> >>> > OK.But when a simple HelloWorld program,which is part of >> >> >>>> >>> > EDK2 >> >> >>>> >>> > sample >> >> >>>> >>> > programs and which is written in c,is renamed to .CPP,we get >> >> >>>> >>> > these >> >> >>>> >>> > relocation issues in-spite of not using any C++ runtime >> >> >>>> >>> > API's. >> >> >>>> >>> > >> >> >>>> >>> >> >> >>>> >>> In UDK or EDK2? >> >> >>>> >>> >> >> >>>> >>> > On Thu, Jan 14, 2016 at 2:39 PM, Ard Biesheuvel >> >> >>>> >>> > ard.biesheuvel@linaro.org >> >> >>>> >>> > wrote: >> >> >>>> >>> >> >> >> >>>> >>> >> On 14 January 2016 at 10:06, Ravikanth MVR >> >> >>>> >>> >> ravikanth.mvr@avagotech.com >> >> >>>> >>> >> wrote: >> >> >>>> >>> >> > Hi Ard, >> >> >>>> >>> >> > >> >> >>>> >>> >> > Hope you remember we speaking about the 0x105 and 0x0 >> >> >>>> >>> >> > relocation >> >> >>>> >>> >> > issues >> >> >>>> >>> >> > which we came across while compiling a simple HelloWorld >> >> >>>> >>> >> > program >> >> >>>> >>> >> > in >> >> >>>> >>> >> > CPP.As >> >> >>>> >>> >> > you said on the other thread(EDK2 mailing list)we need >> >> >>>> >>> >> > some >> >> >>>> >>> >> > changes >> >> >>>> >>> >> > to >> >> >>>> >>> >> > compiler and GenFw utility of UDK,can we take the >> >> >>>> >>> >> > required >> >> >>>> >>> >> > changes >> >> >>>> >>> >> > forward >> >> >>>> >>> >> > and come up with a UDK with this support? >> >> >>>> >>> >> > >> >> >>>> >>> >> > We are stuck at this juncture with this activity and >> >> >>>> >>> >> > would >> >> >>>> >>> >> > need >> >> >>>> >>> >> > your >> >> >>>> >>> >> > help >> >> >>>> >>> >> > badly. >> >> >>>> >>> >> > >> >> >>>> >>> >> >> >> >>>> >>> >> Please forget about UDK, and rebase your work onto the >> >> >>>> >>> >> latest >> >> >>>> >>> >> EDK2 >> >> >>>> >>> >> master branch. There have been many changes to the way >> >> >>>> >>> >> relocations >> >> >>>> >>> >> are >> >> >>>> >>> >> handled, which also impose requirements at link time (i.e., >> >> >>>> >>> >> in >> >> >>>> >>> >> terms >> >> >>>> >>> >> of section alignment, and relative offset between sections >> >> >>>> >>> >> both >> >> >>>> >>> >> in >> >> >>>> >>> >> the >> >> >>>> >>> >> ELF and the PE/COFF versions of the image) >> >> >>>> >>> >> >> >> >>>> >>> >> However, the relocation issue was due to the fact that you >> >> >>>> >>> >> were >> >> >>>> >>> >> using >> >> >>>> >>> >> the Linux version of the C++ runtime, which you cannot use >> >> >>>> >>> >> under >> >> >>>> >>> >> EDK2 >> >> >>>> >>> >> even if we do support those relocation types with the newer >> >> >>>> >>> >> tools. >> >> >>>> >>> >> >> >> >>>> >>> >> Bottom line is that you need to develop your own C++ >> >> >>>> >>> >> minimal >> >> >>>> >>> >> runtime >> >> >>>> >>> >> if you want to run C++ programs under EDK2 >> >> >>>> >>> >> >> >> >>>> >>> >> > On Tue, Jan 5, 2016 at 4:29 PM, Ravikanth MVR >> >> >>>> >>> >> > ravikanth.mvr@avagotech.com >> >> >>>> >>> >> > wrote: >> >> >>>> >>> >> >> >> >> >>>> >>> >> >> +Sada. >> >> >>>> >>> >> >> >> >> >>>> >>> >> >> Thanks. >> >> >>>> >>> >> >> >> >> >>>> >>> >> >> On Wed, Dec 30, 2015 at 8:38 PM, Ard Biesheuvel >> >> >>>> >>> >> >> ard.biesheuvel@linaro.org wrote: >> >> >>>> >>> >> >>> >> >> >>>> >>> >> >>> On 30 December 2015 at 16:02, Leif Lindholm >> >> >>>> >>> >> >>> leif.lindholm@linaro.org >> >> >>>> >>> >> >>> wrote: >> >> >>>> >>> >> >>> > Hi Daniel, >> >> >>>> >>> >> >>> > >> >> >>>> >>> >> >>> > Sorry, your email got stuck in my SPAM folder for >> >> >>>> >>> >> >>> > some >> >> >>>> >>> >> >>> > reason. >> >> >>>> >>> >> >>> > >> >> >>>> >>> >> >>> > On Wed, Dec 23, 2015 at 05:25:21PM -0500, Daniel >> >> >>>> >>> >> >>> > Samuelraj >> >> >>>> >>> >> >>> > wrote: >> >> >>>> >>> >> >>> >> We are able to compile CPP files for X64 using >> >> >>>> >>> >> >>> >> UDK2014 >> >> >>>> >>> >> >>> >> by >> >> >>>> >>> >> >>> >> using >> >> >>>> >>> >> >>> >> Visual >> >> >>>> >>> >> >>> >> Studio. >> >> >>>> >>> >> >>> >> >> >> >>>> >>> >> >>> >> How do we compile the same source for AARCH64? >> >> >>>> >>> >> >>> >> >> >>>> >>> >> >>> Do you mean C++? That is completely unsupported, and is >> >> >>>> >>> >> >>> going >> >> >>>> >>> >> >>> to >> >> >>>> >>> >> >>> be >> >> >>>> >>> >> >>> quite a challenge to implement. Note that you cannot >> >> >>>> >>> >> >>> rely >> >> >>>> >>> >> >>> on >> >> >>>> >>> >> >>> the >> >> >>>> >>> >> >>> C++ >> >> >>>> >>> >> >>> runtime for various reasons (including, but not limited >> >> >>>> >>> >> >>> to, >> >> >>>> >>> >> >>> the >> >> >>>> >>> >> >>> fact >> >> >>>> >>> >> >>> that it uses small model relocations, and is built >> >> >>>> >>> >> >>> against >> >> >>>> >>> >> >>> libc >> >> >>>> >>> >> >>> on >> >> >>>> >>> >> >>> Linux) I wonder how that even works on Visual Studio >> >> >>>> >>> >> >>> for >> >> >>>> >>> >> >>> X64, >> >> >>>> >>> >> >>> since >> >> >>>> >>> >> >>> the code you build will try to call libc functions from >> >> >>>> >>> >> >>> the >> >> >>>> >>> >> >>> VC >> >> >>>> >>> >> >>> runtime >> >> >>>> >>> >> >>> library. >> >> >>>> >>> >> >>> >> >> >>>> >>> >> >>> There has been some discussion about this recently on >> >> >>>> >>> >> >>> the >> >> >>>> >>> >> >>> list. >> >> >>>> >>> >> >>> If >> >> >>>> >>> >> >>> you >> >> >>>> >>> >> >>> disable exceptions and RTTI, and reimplement your new >> >> >>>> >>> >> >>> and >> >> >>>> >>> >> >>> delete >> >> >>>> >>> >> >>> operators, you may be able to build code that does not >> >> >>>> >>> >> >>> rely >> >> >>>> >>> >> >>> on >> >> >>>> >>> >> >>> advanced C++ runtime features. >> >> >>>> >>> >> >>> >> >> >>>> >>> >> >>> -- >> >> >>>> >>> >> >>> Ard. >> >> >>>> >>> >> >> >> >> >>>> >>> >> >> >> >> >>>> >>> >> > >> >> >>>> >>> > >> >> >>>> >>> > >> >> >>>> >> >> >> >>>> >> >> >> >>>> > >> >> >>> >> >> >>> >> > >> > > >