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