diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c
b/BaseTools/Source/C/GenFw/Elf64Convert.c
index 90d80a22daf2..0a1329f0f668 100644
--- a/BaseTools/Source/C/GenFw/Elf64Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
@@ -767,6 +767,9 @@ WriteSections64 (
case R_AARCH64_LD_PREL_LO19:
case R_AARCH64_CALL26:
case R_AARCH64_JUMP26:
+ case R_AARCH64_PREL64:
+ case R_AARCH64_PREL32:
+ case R_AARCH64_PREL16:
//
// The GCC toolchains (i.e., binutils) may corrupt section relative
// relocations when emitting relocation sections into fully linked
@@ -869,6 +872,11 @@ WriteRelocations64 (
case R_AARCH64_JUMP26:
break;
+ case R_AARCH64_PREL64:
+ case R_AARCH64_PREL32:
+ case R_AARCH64_PREL16:
+ break;
+
case R_AARCH64_ADR_PREL_PG_HI21:
case R_AARCH64_ADD_ABS_LO12_NC:
case R_AARCH64_LDST8_ABS_LO12_NC:
--
Ard.
> "gcc" -g -fshort-wchar -fno-strict-aliasing -Wall -Werror
> -Wno-array-bounds -ffunction-sections -fdata-sections -c -include AutoGen.h
> -DSTRING_ARRAY_NAME=HelloWorldStrings -g -Os -fshort-wchar
> -fno-strict-aliasing -fno-stack-protector -Wall -Werror -Wno-array-bounds -c
> -include AutoGen.h -mcmodel=large -mlittle-endian -fno-short-enums
> -save-temps -fverbose-asm -fsigned-char -ffunction-sections -fdata-sections
> -fomit-frame-pointer -fno-builtin -Wno-address -Wno-unused-but-set-variable
> -o
> /home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/OUTPUT/./AutoGen.obj
> -I/home/ekd2_new/MyWorkSpace/MdeModulePkg/Application/HelloWorld
> -I/home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG
> -I/home/ekd2_new/MyWorkSpace/MdePkg
> -I/home/ekd2_new/MyWorkSpace/MdePkg/Include
> -I/home/ekd2_new/MyWorkSpace/MdePkg/Include/AArch64
> -I/home/ekd2_new/MyWorkSpace/MdeModulePkg
> -I/home/ekd2_new/MyWorkSpace/MdeModulePkg/Include
> /home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/AutoGen.c
> "ar" -cr
> /home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/OUTPUT/HelloWorld.lib
> @/home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/OUTPUT/object_files.lst
> "ld" -o
> /home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
> -Ttext=0x0 --emit-relocs -nostdlib --gc-sections -u _ModuleEntryPoint -e
> _ModuleEntryPoint -Map
> /home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.map
> --start-group
> @/home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/OUTPUT/static_library_files.lst
> --end-group
> "echo" objcopy not needed for
> /home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
> objcopy not needed for
> /home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
> cp -f
> /home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
> /home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.debug
> echo --strip-unneeded -R .eh_frame
> /home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
> --strip-unneeded -R .eh_frame
> /home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
> echo
> /home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
> /home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
> cp -f
> /home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.debug
> /home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64
> "GenFw" -e UEFI_APPLICATION -o
> /home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.efi
> /home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
> GenFw: ERROR 3000: Invalid
> WriteSections64():
> /home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
> unsupported ELF EM_AARCH64 relocation 0x105.
> GenFw: ERROR 3000: Invalid
> make: ***
> [/home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.efi]
> Error 2
> WriteRelocations64():
> /home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
> unsupported ELF EM_AARCH64 relocation 0x105.
>
>
> build.py...
> : error 7000: Failed to execute command
> make all
> [/home/ekd2_new/MyWorkSpace/Build/MdeModule/RELEASE_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld]
>
> - Failed -
> Build end time: 11:29:54, Feb.04 2016
> Build total time: 00:00:09
>
> Thanks
> Ravi
>
> On Wed, Feb 3, 2016 at 12:54 AM, Ravikanth MVR
ravikanth.mvr@broadcom.com
> wrote:
>>
>> Ard,
>>
>> I tried building the EDK2 with the below configuration and ended up with
>> the same result as before.Would try out the scenario with GCC4.9/GCC4.8
>> compiler+Toolchain:GCC49/GCC48 and target set to AARCH64. Would let you know
>> the results.
>>
>> Thanks.
>>
>> On Tue, Feb 2, 2016 at 10:18 PM, Ravikanth MVR
>>
ravikanth.mvr@broadcom.com wrote:
>>>
>>> Ard,
>>> Below is my configuration
>>>
>>> ACTIVE_PLATFORM = MdeModulePkg/MdeModulePkg.dsc
>>> TARGET = RELEASE
>>> TARGET_ARCH = AARCH64
>>> TOOL_CHAIN_CONF = Conf/tools_def.txt
>>> TOOL_CHAIN_TAG = GCC49
>>>
>>> And GCC5.0.0 compiler is being used to compile the code or you want me to
>>> use the GCC4.9 compiler to compile as well?
>>>
>>> Thanks.
>>>
>>> On Tue, Feb 2, 2016 at 8:56 PM, Ravikanth MVR
>>>
ravikanth.mvr@broadcom.com wrote:
>>>>
>>>> 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.
>>>>> >> >> >>>> >>> >> >>
>>>>> >> >> >>>> >>> >> >>
>>>>> >> >> >>>> >>> >> >
>>>>> >> >> >>>> >>> >
>>>>> >> >> >>>> >>> >
>>>>> >> >> >>>> >>
>>>>> >> >> >>>> >>
>>>>> >> >> >>>> >
>>>>> >> >> >>>
>>>>> >> >> >>>
>>>>> >> >
>>>>> >> >
>>>>> >
>>>>> >
>>>>
>>>>
>>>
>>
>