Re: [edk2] gcc arm build issue

Subject: Re: [edk2] gcc arm build issue

From: Andrew Fish <afish@apple.com>

To: edk2-devel@lists.sourceforge.net

Date: 2010-07-31 02:52:42

Jerry,

OK. I also checked in a temp version of the PE/COFF library in the ArmPkg that deals with MOVT relocations. This should enable you to get to the prompt.

Andrew Fish





On Jul 30, 2010, at 3:11 PM, Kim, Jerry wrote:

Andrew,
 
Adding the 2 case statements for the 2 routines resolved my issue and have verified the pc relative access is occurring correctly.
 
Thanks
Jerry
 
 
From: Andrew Fish [mailto:afish@apple.com] 
Sent: Friday, July 30, 2010 10:35 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] gcc arm build issue
 
Jerry,
 
From the ARM ELF Binding 0x1e (30) is R_ARM_THM_JUMP24. This is a PC relative relocation that has no place in a statically linked executable image.....
 
I think I may need to add the entire list of PC relative relocations for ARM to the GenFw so they can be skipped. This way new compiler versions or optimization flags won't break us in the future.
 
There are two switch statements in BaseTools/Source/C/GenFw/Elf32Convert.c that need to get updated.  If you add this relocation to the case statement of the ones to skip ti should work around the problem. I don't see 30 define in BaseTools/Source/C/GenFw/elf_common.h 
 
Here is what needs to change.
 
          switch (ELF32_R_TYPE(Rel->r_info)) {
          case R_ARM_RBASE:
            // No relocation - no action required
 
          case R_ARM_PC24:
          case R_ARM_XPC25:
          case R_ARM_THM_PC22:
          case R_ARM_THM_JUMP19:
          case R_ARM_CALL:
          case R_ARM_JMP24:
          case 0x1e:
            // Thease are all PC-relative relocations and don't require modification
            // GCC does not seem to have the concept of a application that just needs to get relocated.
            break;
 
          case R_ARM_THM_MOVW_ABS_NC:
            // MOVW is only lower 16-bits of the addres
            Address = (UINT16)(Sym->st_value - SymShdr->sh_addr + mCoffSectionsOffset[Sym->st_shndx]);
            ThumbMovtImmediatePatch ((UINT16 *)Targ, Address);
            break;
 
          case R_ARM_THM_MOVT_ABS:
            // MOVT is only upper 16-bits of the addres
            Address = (UINT16)((Sym->st_value - SymShdr->sh_addr + mCoffSectionsOffset[Sym->st_shndx]) >> 16);
            ThumbMovtImmediatePatch ((UINT16 *)Targ, Address);
            break;
 
          case R_ARM_ABS32:
          case R_ARM_RABS32:
            //
            // Absolute relocation.
            //
            *(UINT32 *)Targ = *(UINT32 *)Targ - SymShdr->sh_addr + mCoffSectionsOffset[Sym->st_shndx];
            break;
 
          default:
            Error (NULL, 0, 3000, "Invalid", "WriteSections (): %s unsupported ELF EM_ARM relocation 0x%x.", mInImageName, (unsigned) ELF32_R_TYPE(Rel->r_info));
          }
        }
 
 
            switch (ELF32_R_TYPE(Rel->r_info)) {
            case R_ARM_RBASE: 
              // No relocation - no action required
            case R_ARM_PC24:
            case R_ARM_XPC25:
            case R_ARM_THM_PC22:
            case R_ARM_THM_JUMP19:
            case R_ARM_CALL:
            case R_ARM_JMP24:
            case 0x1e:
              // Thease are all PC-relative relocations and don't require modification
              break;
 
            case R_ARM_THM_MOVW_ABS_NC:
              CoffAddFixup (
                mCoffSectionsOffset[RelShdr->sh_info]
                + (Rel->r_offset - SecShdr->sh_addr),
                EFI_IMAGE_REL_BASED_ARM_THUMB_MOVW
                );
              break;
 
            case R_ARM_THM_MOVT_ABS:
              CoffAddFixup (
                mCoffSectionsOffset[RelShdr->sh_info]
                + (Rel->r_offset - SecShdr->sh_addr),
                EFI_IMAGE_REL_BASED_ARM_THUMB_MOVT
                );
 
              // The relocation entry needs to contain the lower 16-bits so we can do math
              CoffAddFixupEntry ((UINT16)(Sym->st_value - SymShdr->sh_addr + mCoffSectionsOffset[Sym->st_shndx]));
              break;
 
            case R_ARM_ABS32:
            case R_ARM_RABS32:
              CoffAddFixup (
                mCoffSectionsOffset[RelShdr->sh_info]
                + (Rel->r_offset - SecShdr->sh_addr),
                EFI_IMAGE_REL_BASED_HIGHLOW
                );
              break;
 
           default:
              Error (NULL, 0, 3000, "Invalid", "WriteRelocations(): %s unsupported ELF EM_ARM relocation 0x%x.", mInImageName, (unsigned) ELF32_R_TYPE(Rel->r_info));
            }
          } else {
            Error (NULL, 0, 3000, "Not Supported", "This tool does not support relocations for ELF with e_machine %u (processor type).", (unsigned) mEhdr->e_machine);
          }
 
Why don't you give that a try. You will have to rebuild the tools from the BaseTools directory as this does not happen as part of the build. Binaries of the tools are checked in for Windows, so those are the tools you are probably using. 
 
I'm sending this email from an airplane, yea Alaska Air for adding WiFi on their flights, so it may be a while before I can check in the real fix. Also if I check into the BaseTools project we will have to wait for the sync with the edk2. 
 
Andrew Fish
 
 

 

 
On Jul 30, 2010, at 8:58 AM, Kim, Jerry wrote:


Hi Andrew,
 
Adding the flag did create reloc tables but GenFw is now reporting errors
 
GenFw -e SEC -o c:\edk2\Build\BeagleBoard\DEBUG_ARMGCC\ARM\BeagleBoardPkg\Sec\Sec\DEBUG\BeagleBoardS
ec.efi c:\edk2\Build\BeagleBoard\DEBUG_ARMGCC\ARM\BeagleBoardPkg\Sec\Sec\DEBUG\BeagleBoardSec.dll
GenFw: ERROR 3000: Invalid
  WriteSections (): c:\edk2\Build\BeagleBoard\DEBUG_ARMGCC\ARM\BeagleBoardPkg\Sec\Sec\DEBUG\BeagleBo
ardSec.dll unsupported ELF EM_ARM relocation 0x1e.
GenFw: ERROR 3000: Invalid
  WriteSections (): c:\edk2\Build\BeagleBoard\DEBUG_ARMGCC\ARM\BeagleBoardPkg\Sec\Sec\DEBUG\BeagleBo
ardSec.dll unsupported ELF EM_ARM relocation 0x1e.
GenFw: ERROR 3000: Invalid
  WriteSections (): c:\edk2\Build\BeagleBoard\DEBUG_ARMGCC\ARM\BeagleBoardPkg\Sec\Sec\DEBUG\BeagleBo
ardSec.dll unsupported ELF EM_ARM relocation 0x1e.
 
Regards
Jerry
 
From: Andrew Fish [mailto:afish@apple.com] 
Sent: Thursday, July 29, 2010 9:30 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] gcc arm build issue
 
Jerry,
 
Try updating your Conf/tools_def.txt and add --emit-relocs  back to the *_ARMGCC_ARM_DLINK_FLAGS. I think this may be the bug your are seeing?
 
*_ARMGCC_ARM_DLINK_FLAGS =  $(ARCHDLINK_FLAGS) --emit-relocs --oformat=elf32-littlearm -nostdlib -u $(IMAGE_ENTRY_POINT) -e $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map
 
 
Andrew Fish
 
 

 

 
On Jul 29, 2010, at 5:48 PM, Kim, Jerry wrote:



Andrew
 
For whatever reason there doesnt seem to be any relocation entries with the BeagleBoardSec.dll.
 
When running arm-none-eabi-objdump BeagleBoardSec.dll r.  I get the following output
 
C:\edk2\Build\BeagleBoard\DEBUG_ARMGCC\ARM\BeagleBoardPkg\Sec\Sec\DEBUG>arm-none-eabi-objdump Beagle
BoardSec.dll -r
 
BeagleBoardSec.dll:     file format elf32-littlearm
 
As a result I get the following when running  :
 
C:\edk2\Build\BeagleBoard\DEBUG_ARMGCC\ARM\BeagleBoardPkg\Sec\Sec\DEBUG>dumpbin /relocations beagleboardsec.efi
Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.
 
 
Dump of file beagleboardsec.efi
 
File Type: EXECUTABLE IMAGE
 
  Summary
 
        1080 .data
          A0 .debug
        D5A0 .text
 
 
Just to make sure its not my build env I deleted my \edk2 directory and re-synced with the latest in https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2
 
Ive attached the build scripts Im using as well as the dll.
 
 
Regards
Jerry
 
From: Andrew Fish [mailto:afish@apple.com] 
Sent: Thursday, July 29, 2010 11:28 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] gcc arm build issue
 
Jerry,
 
If you are loading into memory with jtag you can use the checked in 0x80008000 address so it is the same as the Mask ROM boot. 
 
This is the RealView script that is checked into source control that we use.
A build tool converts the ZZZZZZ into the path of your build system and copies it to the build output directory Build/BeagleBoard/DEBUG_XCODE32 
 
The uboot example used a load address of  0x80208000 to not overwrite uboot while you were doing the copy. 
 
Andrew Fish
 
 




 
On Jul 29, 2010, at 11:01 AM, Kim, Jerry wrote:




Forgot to mention the way Im loading the image is through jtag.  Im loading beagleboard_efi.fd into address 0x80208000.  Once loaded I set the pc to the instruction which jumps to  _ModuleEntryPoint.  This eventually leads me to the movt instruction in CreateHobList.
 
Regards
Jerry
 
From: Kim, Jerry [mailto:jerryk@ti.com] 
Sent: Thursday, July 29, 2010 10:54 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] gcc arm build issue
 
Hi Andrew,
 
Im using VS2008 so Ill try dumping the module tables and compare to what you listed below. 
 
I last synced early last week so I would have grabbed your fixes.
 
Ill let you know when I have something of interest.
 
Regards
Jerry
 
From: Andrew Fish [mailto:afish@apple.com] 
Sent: Thursday, July 29, 2010 10:33 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] gcc arm build issue
 
Jerry,
 
For tools the source code is checked int the BaseTools project and then it is validated and synced to the edk2. 
 
So the MOVW/MOVT support got added to BaseTools Wed, 24 Mar 2010:
r1943 | andrewfish | 2010-03-31 11:13:20 -0700 (Wed, 31 Mar 2010) | 2 lines
 
Update comment based on finding an older version of the ARM ELF specification that the code conforms to.
 
------------------------------------------------------------------------
r1941 | andrewfish | 2010-03-24 10:29:20 -0700 (Wed, 24 Mar 2010) | 2 lines
 
Add support for ARM MOVW & MOVT relocations. These relocations are different than other relocations as each instruction only enocodes 1/2 of the 32-bit address so the MOVT that encodes the upper 16-bits requires Addend info in the relocation entry. This is done via Elf32_Rela in ELF by adding the Addend into the relocation data. Usually the Addend is read out of the instruction and the relocation entry points to the instruction. The PE/COFF spec is pending an update to describe ARM MOVW & MOVT relocation types.
 
 
And this was synced to the edk2 Mon, 17 May 2010):
 
svn log GenFw.exe
------------------------------------------------------------------------
r10706 | qhuang8 | 2010-07-27 20:07:30 -0700 (Tue, 27 Jul 2010) | 1 line
 
Sync EDKII BaseTools to BaseTools project r2000
------------------------------------------------------------------------
r10680 | qhuang8 | 2010-07-20 19:46:15 -0700 (Tue, 20 Jul 2010) | 1 line
 
Sync EDKII BaseTools to BaseTools project r1997
------------------------------------------------------------------------
r10607 | qhuang8 | 2010-06-28 02:33:10 -0700 (Mon, 28 Jun 2010) | 1 line
 
Sync EDKII BaseTools to BaseTools project r1988
------------------------------------------------------------------------
r10502 | lgao4 | 2010-05-17 22:04:32 -0700 (Mon, 17 May 2010) | 1 line
 
Sync EDKII BaseTools to BaseTools project r1971
 
 
 
So I'm guessing it is not an issue with the version of the tools you are using?
 
Andrew Fish
 
 

 

 
On Jul 28, 2010, at 11:30 PM, Andrew Fish wrote:

 

Jerry,
 
I did some more checking and it looks like your case should be covered since the tools have been ported to support MOVW and MOVT in the ELF to PE/COFF conversion process.  You would only have a problem when you tried to load a PE/COFF image into memory as part of EFI.
 
edk2\BaseTools\Source\C\GenFw\Efl32Convert.c has the code that processes MOVW and MOVT.  You can search for EFI_IMAGE_REL_BASED_ARM_THUMB_MOVW and EFI_IMAGE_REL_BASED_ARM_THUMB_MOVT.
 
So we need to figure out what is going on in your case. Do you have Visual Studio installed on your system. If so you can do the following 
 
dumpbin /RELOCATIONS edk2\Build\BeagleBoard\DEBUG_ARMGCC\ARM\BeagleBoardPkg\Sec\Sec\DEBUG\BeagleBoardSec.efi
 
You should get output that looks like:
 
Microsoft (R) COFF/PE Dumper Version 7.10.3077
Copyright (C) Microsoft Corporation.  All rights reserved.
 
 
Dump of file BeagleBoardSec.efi
 
File Type: EXECUTABLE IMAGE
 
BASE RELOCATIONS #3
       0 RVA,      144 SizeOfBlock
     34A  UNKNOWN(B)                   
     34E  UNKNOWN(C)                   
     598  UNKNOWN(F)                   
     456  UNKNOWN(B)                   
     45A  UNKNOWN(C)                   
     650  UNKNOWN(F)                   
     466  UNKNOWN(B)                   
     46A  UNKNOWN(C)                   
     638  UNKNOWN(F)                   
     4A4  UNKNOWN(B)                   
     4A8  UNKNOWN(C)                   
     5CC  UNKNOWN(F)                   
     4C0  UNKNOWN(B)                   
     4C4  UNKNOWN(C)                   
     670  LOW                    D3AF
     ...
 
UNKNOWN(B)  - is the MOVW relocation that I added
UNKNOWN(C)  - is the MOVT relocation that I added
UNKNOWN(?)  - There is an entry following MOVT that has a bogus type as all 16-bits are used as the addend.  
 
You can also Dump the ELF file
arm-none-eabi-objdump BeagleBoardSec.dll -r
 
BeagleBoardSec.dll:     file format elf32-littlearm
 
RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE 
0000007c R_ARM_CALL        CEntryPoint
00000094 R_ARM_THM_CALL    TimerBase
000000a8 R_ARM_THM_CALL    MmioOr32
000000b8 R_ARM_THM_CALL    MmioWrite32
000000c8 R_ARM_THM_CALL    MmioWrite32
000000d8 R_ARM_THM_CALL    MmioWrite32
000000e8 R_ARM_THM_CALL    MmioWrite32
000000f8 R_ARM_THM_CALL    MmioWrite32
000000fc R_ARM_THM_CALL    DebugPrintEnabled
0000010a R_ARM_THM_MOVW_ABS_NC  .LC0
0000010e R_ARM_THM_MOVT_ABS  .LC0
00000112 R_ARM_THM_CALL    DebugPrint
 
So the ELF file has a lot of PC relative relocations that are not needed in a static executable. These are more like things you would see in an object that needs to get linked.  R_ARM_CALL and R_ARM_THM_CALL are relative relocations so they do not map to PE/COFF relocation. 
 
PE/COFF includes the header in the loaded image and ELF does not. So offsets in the PE/COFF image have the size of the header (0x240) added in.  The size of the header is a field in the PE/COFF header. 
 
    34A  UNKNOWN(B)     //   0000010a R_ARM_THM_MOVW_ABS_NC  .LC0       
     34E  UNKNOWN(C)    //   0000010e R_ARM_THM_MOVT_ABS  .LC0
     598  UNKNOWN(F)     // Extra entry to store MOVT addend                
 
 
dumpbin /HEADERS edk2\Build\BeagleBoard\DEBUG_ARMGCC\ARM\BeagleBoardPkg\Sec\Sec\DEBUG\BeagleBoardSec.efi
 
Microsoft (R) COFF/PE Dumper Version 7.10.3077
Copyright (C) Microsoft Corporation.  All rights reserved.
 
 
Dump of file BeagleBoardSec.efi
 
PE signature found
 
File Type: EXECUTABLE IMAGE
 
FILE HEADER VALUES
             1C2 machine (Thumb)
               4 number of sections
               0 time date stamp Wed Dec 31 16:00:00 1969
               0 file pointer to symbol table
               0 number of symbols
              E0 size of optional header
             10E characteristics
                   Executable
                   Line numbers stripped
                   Symbols stripped
                   32 bit word machine
 
OPTIONAL HEADER VALUES
             10B magic # (PE32)
            0.00 linker version
           11490 size of code
            1090 size of initialized data
               0 size of uninitialized data
             240 entry point (00000240)
             240 base of code
           116D0 base of data
               0 image base (00000000 to 000139BF)
              20 section alignment
              20 file alignment
            0.00 operating system version
            0.00 image version
            0.00 subsystem version
               0 Win32 version
           139C0 size of image
             240 size of headers
               0 checksum
               B subsystem (EFI Boot Service Driver)
               0 DLL characteristics
               0 size of stack reserve
               0 size of stack commit
               0 size of heap reserve
               0 size of heap commit
               0 loader flags
              10 number of directories
               0 [       0] RVA [size] of Export Directory
               0 [       0] RVA [size] of Import Directory
               0 [       0] RVA [size] of Resource Directory
               0 [       0] RVA [size] of Exception Directory
               0 [       0] RVA [size] of Certificates Directory
           12760 [    11C0] RVA [size] of Base Relocation Directory
           13920 [      A0] RVA [size] of Debug Directory
               0 [       0] RVA [size] of Architecture Directory
               0 [       0] RVA [size] of Global Pointer Directory
               0 [       0] RVA [size] of Thread Storage Directory
               0 [       0] RVA [size] of Load Configuration Directory
               0 [       0] RVA [size] of Bound Import Directory
               0 [       0] RVA [size] of Import Address Table Directory
               0 [       0] RVA [size] of Delay Import Directory
               0 [       0] RVA [size] of COM Descriptor Directory
               0 [       0] RVA [size] of Reserved Directory
 
Andrew Fish
 
PS If you don't have Visual Studio can you send me the ELF and PE/COFF file the build produced so I can take a look at them?

 

 
On Jul 27, 2010, at 5:12 PM, Kim, Jerry wrote:

 

Hi,
 
During boot-up I see the code to jump to the _ModuleEntry code of beagleboardsec.dll.  Subsequently the code jumps to Sec.c:CEntryPoint and then CreateHobList.  Inside CreateHobList there is a reference to _gPcd_FixedAtBuild_PcdPrePiCpuMemorySize which appears *not* to have been fixed-up to represent the load address of beagleboardsec.dll.
 
In the screenshot below for line NST:80208CD2, r14 is suppose to get the address of _gPcd_FixedAtBuild_PcdPrePiCpuMemorySize, which is (0x80213B38), instead r14 is getting 0x000137D8.
 
<image001.png>
 
 
 
Is there a utility which is suppose to fixup these global variables?
 
Regards
Jerry
 
From: Andrew Fish [mailto:afish@apple.com] 
Sent: Monday, July 26, 2010 3:21 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] gcc arm build issue
 
It patches the FD so it contains the info the OMAP35xx mask ROM is looking for to turn on DRAM and jump into the FV to start running the EFI code.
 
Andrew Fish
 
 






 
On Jul 26, 2010, at 3:19 PM, Kim, Jerry wrote:






Disregard, I see its a tool part of the beagleboard tree
 
Jerry
 
From: Kim, Jerry 
Sent: Monday, July 26, 2010 3:15 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] gcc arm build issue
 
Andrew,
 
In ba.bat there is a reference to generateimage.  Would you know what this does and where I can find it?
 
Regards
Jerry
 
 
From: Kim, Jerry [mailto:jerryk@ti.com] 
Sent: Monday, July 26, 2010 11:57 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] gcc arm build issue
 
Hi Andrew,
 
Ive verified Im able to get pass the link phase and I see the .fd file as well.
 
Thanks for all you help.
 
Regards
Jerry
 
From: Andrew Fish [mailto:afish@apple.com] 
Sent: Saturday, July 24, 2010 10:40 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] gcc arm build issue
 
I think I fixed the newest CS version. Please give it a try. 
 
I've not had a chance to test the binary, but since I ported code from the RVCT side of the world there is a very good chance it should work. 
 
Andrew Fish
 
 

 

 
On Jul 24, 2010, at 1:42 PM, Kim, Jerry wrote:

 

okay, I'll try using your version.  thanks for the help.
 
Regards
Jerry
 

From: Andrew Fish [afish@apple.com]
Sent: Saturday, July 24, 2010 12:11 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] gcc arm build issue

I think we may just be getting lucky. I added Div64 to HelloWorld and I made it not link.  
 
 undefined reference to `__aeabi_ldivmod'
 
 
long long
Div64 (long long a, long long b) {
  return a/b;
}
 
I'm thinking different versions of the compiler may do slightly different code gen.  I noticed the compiler tries to do math some times for / in place of calling the intrinsic. 
 
Andrew Fish
 
 
 
On Jul 24, 2010, at 10:59 AM, Kim, Jerry wrote:

 

Andrew,
 
Heres my gcc version
 
C:\edk2>"c:\Program Files\CodeSourcery\Sourcery G++ Lite\bin"\arm-none-eabi-gcc -v
Using built-in specs.
Target: arm-none-eabi
Configured with: /scratch/julian/2010q1-release-eabi-lite/src/gcc-4.4-2010q1/configure --build=i686-
pc-linux-gnu --host=i686-mingw32 --target=arm-none-eabi --enable-threads --disable-libmudflap --disa
ble-libssp --disable-libstdcxx-pch --enable-extra-sgxxlite-multilibs --with-gnu-as --with-gnu-ld --w
ith-specs='%{O2:%{!fno-remove-local-statics: -fremove-local-statics}} %{O*:%{O|O0|O1|O2|Os:;:%{!fno-
remove-local-statics: -fremove-local-statics}}}' --enable-languages=c,c++ --disable-shared --disable
-lto --with-newlib --with-pkgversion='Sourcery G++ Lite 2010q1-188' --with-bugurl=https://support.co
desourcery.com/GNUToolchain/ --disable-nls --prefix=/opt/codesourcery --with-headers=yes --with-sysr
oot=/opt/codesourcery/arm-none-eabi --with-build-sysroot=/scratch/julian/2010q1-release-eabi-lite/in
stall/host-i686-mingw32/arm-none-eabi --with-libiconv-prefix=/scratch/julian/2010q1-release-eabi-lit
e/obj/host-libs-2010q1-188-arm-none-eabi-i686-mingw32/usr --with-gmp=/scratch/julian/2010q1-release-
eabi-lite/obj/host-libs-2010q1-188-arm-none-eabi-i686-mingw32/usr --with-mpfr=/scratch/julian/2010q1
-release-eabi-lite/obj/host-libs-2010q1-188-arm-none-eabi-i686-mingw32/usr --with-ppl=/scratch/julia
n/2010q1-release-eabi-lite/obj/host-libs-2010q1-188-arm-none-eabi-i686-mingw32/usr --with-host-libst
dcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-cloog=/scratch/julian/2010q1-releas
e-eabi-lite/obj/host-libs-2010q1-188-arm-none-eabi-i686-mingw32/usr --disable-libgomp --enable-poiso
n-system-directories --with-build-time-tools=/scratch/julian/2010q1-release-eabi-lite/obj/tools-i686
-pc-linux-gnu-2010q1-188-arm-none-eabi-i686-mingw32/arm-none-eabi/bin --with-build-time-tools=/scrat
ch/julian/2010q1-release-eabi-lite/obj/tools-i686-pc-linux-gnu-2010q1-188-arm-none-eabi-i686-mingw32
/arm-none-eabi/bin
Thread model: single
gcc version 4.4.1 (Sourcery G++ Lite 2010q1-188)
 
do you know which intrinsic function your version of gcc maps the / to?
 
Regards
Jerry
 
 
From: Andrew Fish [mailto:afish@apple.com] 
Sent: Saturday, July 24, 2010 10:34 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] gcc arm build issue
 
Jerry,
 
What version of gcc are you using? 
 
Here is my dump of gcc -v
Using built-in specs.
Target: arm-none-eabi
Configured with: /scratch/julian/2009q3-respin-eabi-lite/src/gcc-4.4/configure --build=i686-pc-linux-gnu --host=i686-mingw32 --target=arm-none-eabi --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --enable-extra-sgxxlite-multilibs --with-gnu-as --with-gnu-ld --with-specs='%{O2:%{!fno-remove-local-statics: -fremove-local-statics}} %{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics: -fremove-local-statics}}}' --enable-languages=c,c++ --disable-shared --disable-lto --with-newlib --with-pkgversion='Sourcery G++ Lite 2009q3-68' --with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls --prefix=/opt/codesourcery --with-headers=yes --with-sysroot=/opt/codesourcery/arm-none-eabi --with-build-sysroot=/scratch/julian/2009q3-respin-eabi-lite/install/host-i686-mingw32/arm-none-eabi --with-libiconv-prefix=/scratch/julian/2009q3-respin-eabi-lite/obj/host-libs-2009q3-68-arm-none-eabi-i686-mingw32/usr --with-gmp=/scratch/julian/2009q3-respin-eabi-lite/obj/host-libs-2009q3-68-arm-none-eabi-i686-mingw32/usr --with-mpfr=/scratch/julian/2009q3-respin-eabi-lite/obj/host-libs-2009q3-68-arm-none-eabi-i686-mingw32/usr --with-ppl=/scratch/julian/2009q3-respin-eabi-lite/obj/host-libs-2009q3-68-arm-none-eabi-i686-mingw32/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-cloog=/scratch/julian/2009q3-respin-eabi-lite/obj/host-libs-2009q3-68-arm-none-eabi-i686-mingw32/usr --disable-libgomp --enable-poison-system-directories --with-build-time-tools=/scratch/julian/2009q3-respin-eabi-lite/obj/tools-i686-pc-linux-gnu-2009q3-68-arm-none-eabi-i686-mingw32/arm-none-eabi/bin --with-build-time-tools=/scratch/julian/2009q3-respin-eabi-lite/obj/tools-i686-pc-linux-gnu-2009q3-68-arm-none-eabi-i686-mingw32/arm-none-eabi/bin
Thread model: single
gcc version 4.4.1 (Sourcery G++ Lite 2009q3-68) 
 
 
Andrew Fish
 
 
 
 
On Jul 24, 2010, at 6:54 AM, Kim, Jerry wrote:

 

Andrew,
 
Thanks for the reply.
 
Im still not able to link successfully.  Using the batch file you pointed me resulted in the following link error
 
c:\edk2\Omap35xxPkg\Library\Omap35xxTimerLib/TimerLib.c:36: undefined reference to `__aeabi_uldivmod'
 
I did see that CompilerIntrinsicsLib.lib is in the link library list.  I did find the missing function being implemented in \edk2\ArmPkg\Library\CompilerIntrinsicsLib\arm\uldiv.asm. 
 
 From what I can deduce reading CompilerInstrinsicslib.inf, it looks like the file gets assembled for RCVT but not for gcc arm.  I assume because gcc arm already provides libgcc.a which contains the routines (could someone confirm?).
 
We don't link against libcc.a. We have all our own libraries in the CompilerIntrinsicLib. 

 

 
This makes me believe there is something wrong in my configuration/setup and I need to determine why my configuration cant find the libgcc.a file.
 
Maybe your have a different version of gcc and the code gen is different?

 

 
Regards
Jerry
 
 
 
From: Andrew Fish [mailto:afish@apple.com] 
Sent: Thursday, July 22, 2010 8:23 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] gcc arm build issue
 
Jerry,
 
I checked in fixes to the build break you mentioned. 
 
>From a DOS box try:
cd BeagleBoardPkg
ba.bat
 
This builds with gcc for me. 
 
Andrew Fish
 
PS
 
Also the Conf\build_rule.txt Conf\tools_def.txt are cached copies of BaseTools\Conf\build_rule.template and BaseTools\Conf\tools_def.template. The idea is you can update the *.templates to match where your tools were installed, and not need to check that into source control. You have to manually delete the *.txt files if the *.template files get update. 
 
So when ever you see that a new versions of the BaseTools have been synced with the edk2 you should delete the *.txt files in the Conf directory. 
 
The edksetup.bat file copies the BaseTools\Conf\*.template files to Conf\*.txt if the *.txt files do not exist. 
 
On Jul 22, 2010, at 6:02 PM, Kim, Jerry wrote:

 

Hello,
 
Im trying to build the beaglboard pkg using gcc arm (rev. arm-2010q1-188-arm-none-eabi).  Im getting the following errors
 
"c:/Program Files/CodeSourcery/Sourcery G++ Lite/bin/arm-none-eabi-ld" -o c:\edk2\Build\MdeModule\DE
BUG_ARMGCC\ARM\MdeModulePkg\Application\HelloWorld\HelloWorld\DEBUG\HelloWorld.dll  --oformat=elf32-
littlearm -nostdlib -u _ModuleEntryPoint -e _ModuleEntryPoint -Map c:\edk2\Build\MdeModule\DEBUG_ARM
GCC\ARM\MdeModulePkg\Application\HelloWorld\HelloWorld\DEBUG/HelloWorld.map -(  c:\edk2\Build\MdeMod
ule\DEBUG_ARMGCC\ARM\MdePkg\Library\BasePrintLib\BasePrintLib\OUTPUT\BasePrintLib.lib c:\edk2\Build\
MdeModule\DEBUG_ARMGCC\ARM\MdePkg\Library\BaseLib\BaseLib\OUTPUT\BaseLib.lib c:\edk2\Build\MdeModule
\DEBUG_ARMGCC\ARM\MdePkg\Library\BaseMemoryLib\BaseMemoryLib\OUTPUT\BaseMemoryLib.lib c:\edk2\Build\
MdeModule\DEBUG_ARMGCC\ARM\MdePkg\Library\UefiDebugLibStdErr\UefiDebugLibStdErr\OUTPUT\UefiDebugLibS
tdErr.lib c:\edk2\Build\MdeModule\DEBUG_ARMGCC\ARM\MdePkg\Library\BasePcdLibNull\BasePcdLibNull\OUTP
UT\BasePcdLibNull.lib c:\edk2\Build\MdeModule\DEBUG_ARMGCC\ARM\MdePkg\Library\UefiBootServicesTableL
ib\UefiBootServicesTableLib\OUTPUT\UefiBootServicesTableLib.lib c:\edk2\Build\MdeModule\DEBUG_ARMGCC
\ARM\MdePkg\Library\UefiMemoryAllocationLib\UefiMemoryAllocationLib\OUTPUT\UefiMemoryAllocationLib.l
ib c:\edk2\Build\MdeModule\DEBUG_ARMGCC\ARM\MdePkg\Library\UefiRuntimeServicesTableLib\UefiRuntimeSe
rvicesTableLib\OUTPUT\UefiRuntimeServicesTableLib.lib c:\edk2\Build\MdeModule\DEBUG_ARMGCC\ARM\MdePk
g\Library\UefiDevicePathLib\UefiDevicePathLib\OUTPUT\UefiDevicePathLib.lib c:\edk2\Build\MdeModule\D
EBUG_ARMGCC\ARM\MdePkg\Library\UefiApplicationEntryPoint\UefiApplicationEntryPoint\OUTPUT\UefiApplic
ationEntryPoint.lib c:\edk2\Build\MdeModule\DEBUG_ARMGCC\ARM\MdePkg\Library\UefiLib\UefiLib\OUTPUT\U
efiLib.lib c:\edk2\Build\MdeModule\DEBUG_ARMGCC\ARM\MdeModulePkg\Application\HelloWorld\HelloWorld\O
UTPUT\HelloWorld.lib -)
c:\edk2\Build\MdeModule\DEBUG_ARMGCC\ARM\MdePkg\Library\BasePrintLib\BasePrintLib\OUTPUT\BasePrintLi
b.lib(PrintLibInternal.obj): In function `BasePrintLibSPrintMarker':
c:\edk2\MdePkg\Library\BasePrintLib/PrintLibInternal.c:890: undefined reference to `__aeabi_uidiv'
c:\edk2\MdePkg\Library\BasePrintLib/PrintLibInternal.c:567: undefined reference to `__aeabi_uidivmod
'
c:\edk2\MdePkg\Library\BasePrintLib/PrintLibInternal.c:572: undefined reference to `__aeabi_uidiv'
c:\edk2\Build\MdeModule\DEBUG_ARMGCC\ARM\MdePkg\Library\BasePrintLib\BasePrintLib\OUTPUT\BasePrintLi
b.lib(PrintLibInternal.obj): In function `BasePrintLibFillBuffer':
c:\edk2\MdePkg\Library\BasePrintLib/PrintLibInternal.c:85: undefined reference to `__aeabi_uidiv'
c:\edk2\Build\MdeModule\DEBUG_ARMGCC\ARM\MdePkg\Library\BaseLib\BaseLib\OUTPUT\BaseLib.lib(Math64.ob
j): In function `InternalMathDivU64x32':
c:\edk2\Build\MdeModule\DEBUG_ARMGCC\ARM\MdePkg\Library\BaseLib\BaseLib\OUTPUT\Arm/Math64.iii:152: u
ndefined reference to `__udivdi3'
c:\edk2\Build\MdeModule\DEBUG_ARMGCC\ARM\MdePkg\Library\BaseLib\BaseLib\OUTPUT\BaseLib.lib(Math64.ob
j): In function `InternalMathModU64x32':
c:\edk2\Build\MdeModule\DEBUG_ARMGCC\ARM\MdePkg\Library\BaseLib\BaseLib\OUTPUT\Arm/Math64.iii:162: u
ndefined reference to `__umoddi3'
c:\edk2\Build\MdeModule\DEBUG_ARMGCC\ARM\MdePkg\Library\BaseLib\BaseLib\OUTPUT\BaseLib.lib(Math64.ob
 
 
I was made aware that there are intrinsic libraries which I can compile defined in \edk2\ArmPkg\Library\CompilerIntrinsicsLib but the function names are slightly different and I believe I need to update them to prefix it with __aeabi.  Would anyone have an alternate/quicker solution to this problem?  Ive also tried adding lgcc to the linker switch but the link still fails.
 
Also, it appears the function signature for InitializeDebugAgent() has changed but wasnt updated for the arm version of processor.c and in beagleboardpkg\sec\sec.c.
 
Thanks
Jerry
 
PS: Its worth noting that Im trying to compile this under dos.
 
 
 
 
 
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
 
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
 
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
 
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
 
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
 
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
 
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
 
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
 
<tools_def.txt><beagleboardsec.zip>------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
 
<BeagleBoardSec.zip>------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
 
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel