Re: [edk2] UnixPkg build problem on ubuntu/Maverick

Subject: Re: [edk2] UnixPkg build problem on ubuntu/Maverick

From: Andrew Fish <afish@apple.com>

To: edk2-devel@lists.sourceforge.net

Date: 2011-03-05 18:23:09

John,

I noticed this In you first mail:

which lets me build on a 32bit system, however I still have weird link errors on a X64 build system using the native gcc compiler.

and you output looks like:

"/usr/bin/gcc" -Os -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-missing-braces -Wno-address -Wno-array-bounds -c -include AutoGen.h -D_EFI_P64 -o /src/edk2/Build/UnixX64/DEBUG_ELFGCC/X64/IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei/OUTPUT/./StatusCodePei.obj -I/src/edk2/IntelFrameworkModulePkg/Universal/StatusCode/Pei -I/src/edk2/Build/UnixX64/DEBUG_ELFGCC/X64/IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei/DEBUG -I/src/edk2/MdePkg -I/src/edk2/MdePkg/Include -I/src/edk2/MdePkg/Include/X64 -I/src/edk2/MdeModulePkg -I/src/edk2/MdeModulePkg/Include -I/src/edk2/IntelFrameworkPkg -I/src/edk2/IntelFrameworkPkg/Include -I/src/edk2/IntelFrameworkModulePkg -I/src/edk2/IntelFrameworkModulePkg/Include /src/edk2/IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.c

Jordan can correct me if I'm wrong, but it looks to me if you are using a "native gcc compiler" for x64 you need to have something like ""-DEFIAPI=__attribute__((ms_abi))" -DNO_BUILTIN_VA_FUNCS -mno-red-zone -Wno-address -mcmodel=large" set on the gcc compile line.

You can not use a native Linux X64 gcc compiler as is since the ABI is wrong. The EFI ABI is like the Windows ABI.  Only the SEC uses the AMD64 ABI  as it has to make OS POSIX calls. Calls between SEC and EFI all go through assembly gaskets to convert the calling conventions. 


Your linker errors:
relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC

Seems like your compiler is unhappy that you are generating a relocation. EFI requires relocations as we link every EFI driver/application at zero and the PE/COFF loader loads them into free physical memory. Seem gcc assumes you have virtual memory so every application gets linked at a fixed address and does not require relocations. 

unsupported ELF EM_X86_64 relocation 0x7.

0x7 is R_X86_64_JUMP_SLOT. This relocation has to do with dynamic linking.  EFI executables are statically linked with relocations. Unfortunately it is very hard to make a statically linked image with relocations via gcc. So it is best to use the toolchain exactly as Jordan recommends. 

http://www.x86-64.org/documentation/abi.pdf

Andrew Fish

Calling convention differences:

64bitMicrosoft x64 calling convention[6]Windows (Microsoft compilerIntel compiler)rcx/xmm0, rdx/xmm1, r8/xmm2, r9/xmm3CcallerStack aligned on 16 bytes. 32 bytes shadow space on stack. The specified 8 registers can only be used for parameter number 1,2,3 and 4.AMD64 ABI convention[8]Linux, BSD, Mac (GCC, Intel compiler)rdi, rsi, rdx, rcx, r8, r9, xmm0-7CcallerStack aligned on 16 bytes. Red zone below stack.


http://en.wikipedia.org/wiki/X86_calling_conventions



On Mar 4, 2011, at 11:01 PM, John Kearney wrote:

Hi Andrew,
  Thanks for the quick response.
  Sure I can test the changes. 

  I've attached a log of the build64.sh output with the link error message.

I tried adding -fPIC as suggested in the error messages, this however upsets genfw.


Von: "Andrew Fish" <afish@apple.com>
Gesendet: Mar 5, 2011 4:45:16 AM
An: edk2-devel@lists.sourceforge.net
Betreff: Re: [edk2] UnixPkg build problem on ubuntu/Maverick

Forgot to mention....
For X64 the SEC is a POSIX app with the Unix ABI and all the other modules are EFI ABI. There is gasket code that switches back and forth between the calling convention. To make all this possible the SEC overrides the compiler flags to build a native OS application. 
If I had to guess your issue is in :
[BuildOptions]
   ...
   GCC:*_*_X64_DLINK_FLAGS == -o $(BIN_DIR)/SecMain -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/crt1.o /usr/lib/crti.o -L/usr/X11R6/lib -lXext -lX11 /usr/lib/crtn.o
   GCC:*_*_X64_CC_FLAGS == -m64 -g -fshort-wchar -fno-strict-aliasing -Wall -malign-double -idirafter/usr/include -c -include $(DEST_DIR_DEBUG)/AutoGen.h -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
   GCC:*_*_X64_PP_FLAGS == -m64 -E -x assembler-with-cpp -include $(DEST_DIR_DEBUG)/AutoGen.h
   GCC:*_*_X64_ASM_FLAGS == -m64 -c -x assembler -imacros $(DEST_DIR_DEBUG)/AutoGen.h

If your problem is linking the SEC this is where to look.  
Note on Xcode I ended up moving over to using gcc to link as some of the frame work stuff moved about from OS release to OS release and gcc, being a wrapper for the real compiler know where it was. 
For a quick fix you can probably do a gcc -v and make sure the *_*_X64_DLINK_FLAGS  match.

Andrew Fish

On Mar 4, 2011, at 7:33 PM, Andrew Fish wrote:

John,
Sorry about that. I did my testing on Mac OS X.  I did not realize at the time, but the network driver is using BSD specific network abstractions. We usually fix this by adding  #ifdef __APPLE__ around the non Linux bits.  We can probably do that in this case. We can probably stub out the networking driver the same way. 
Conceptually some one could port the network driver to Linux and BSD Packet Filter is a good example to start with.
I'm not a Linux gcc expert, but I've ported the edk2 code to lots of compilers if you can post the linker errors I may be able to give you some advice on what the issue is and how to fix it.
Andrew Fish
PS I don't have time to check in the fixes tonight, but I'll see if I can do that in the next few days. I would appreciate it you would test it for me. 


On Mar 4, 2011, at 7:02 PM, John Kearney wrote:

I'm sorry if this is the incorrect mailing list for this problem.

I recently updated to the latest trunk of the edk2 sources.
However the build now fails with the following error.

/home/dethrophes/src/edk2/UnixPkg/Include/Common/UnixInclude.h:65: fatal error: net/if_dl.h: No such file or directory
compilation terminated.

doing a quick check shows that these headers were added by andrewfish. 

11106 andrewfish #include <net/if.h>
 11106 andrewfish #include <net/if_dl.h>
 11106 andrewfish #include <ifaddrs.h>
 11106 andrewfish #include <net/bpf.h>
11106 andrewfish #include <net/if.h> 
11106 andrewfish #include <net/if_dl.h>
 
11106 andrewfish #include <ifaddrs.h>
 
11106 andrewfish #include <net/bpf.h>
 

 However if_dh.h is actually a BSD header. So I'm wondering what is the prescribed approach for linux/Ubuntu/Maverick.
 
my current workaround is to remove reference to UnixSnpDxe.inf in the UnixPkg.dsc, UnixPkg.fdf, UnixPkgX64.dsc, UnixPkgX64.fdf
and commenting out  
 
//#include <net/if_dl.h> 
//#include <net/bpf.h>
in  UnixInclude.h

which lets me build on a 32bit system, however I still have weird link errors on a X64 build system using the native gcc compiler.


 
  

NEU: FreePhone - kostenlos mobil telefonieren und surfen!    
Jetzt informieren: http://produkte.web.de/go/webdefreephone
------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
  

Schon gehrt? WEB.DE hat einen genialen Phishing-Filter in die   
Toolbar eingebaut! http://produkte.web.de/go/toolbar
<logapp.log><logapp-fPIC.log>------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel