OK got it!Would build AARCH64 with GCC48/GCC49 .Please correct me if I am wrong.

Thanks.

On Tue, Feb 2, 2016 at 8:54 PM, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

On 2 February 2016 at 16:23, Ravikanth MVR <ravikanth.mvr@broadcom.com> wrote:
> Ard,
>
> I have been using GCC5.0.0(Experimental version).
>
> gcc (Cavium Inc. Version 1.0 build 297) 5.0.0 20141220 (experimental)
>
> I would try with GCC49/48 and let you know.
>

I don't mean the actual compiler, I mean the toolchain definition in
EDK2. You are using ARMGCC or ARMLINUXGCC, neither of which are
suitable for building AArch64. You should use GCC48 or GCC49 instead

--
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.
>> >> >>>> >>> >> >>
>> >> >>>> >>> >> >>
>> >> >>>> >>> >> >
>> >> >>>> >>> >
>> >> >>>> >>> >
>> >> >>>> >>
>> >> >>>> >>
>> >> >>>> >
>> >> >>>
>> >> >>>
>> >
>> >
>
>