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