Hi Jeff,
After applying the patch the `lret` assembles fine, but I get the same error
for the relocation:
Building ... /Users/x/code/ext/edk2/MdeModulePkg/Core/Dxe/DxeMain.inf [X64]
"ld" -arch x86_64 -u __ModuleEntryPoint -e __ModuleEntryPoint -preload
-segalign 0x20 -pie -all_load -dead_strip -seg1addr 0x240 -map
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.map
-read_only_relocs suppress -o
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
-filelist
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/MdeModulePkg/Core/Dxe/DxeMain/OUTPUT/static_library_files.lst
ld: warning: -read_only_relocs cannot be used with x86_64
ld: illegal text-relocation to '_CommonInterruptEntry' in
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/DxeCpuExceptionHandlerLib.lib(ExceptionHandlerAsm.obj)
from 'Exception0Handle' in
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/DxeCpuExceptionHandlerLib.lib(ExceptionHandlerAsm.obj)
for architecture x86_64
make: ***
[/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll]
Error 1
Egon
On 20 Jun 2014, at 3:59 pm, Fan, Jeff <jeff....@intel.com> wrote:
> Hi Andrew,
> LRET should be used to pass more GCC compilers build.
> I also agree with using relative address instead of absolute address in
> assembly code.
>
> Hi, Egon
> Could you try this attached patch to check if it could pass your compiler
> build?
>
> Thanks!
> Jeff
> From: Andrew Fish [mailto:af...@apple.com]
> Sent: Friday, June 20, 2014 6:50 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] Building on OS X
>
>
> On Jun 19, 2014, at 2:51 PM, Andrew Fish <af...@apple.com> wrote:
>
>
>
> On Jun 19, 2014, at 2:39 PM, Reza Jelveh <reza.jel...@tuhh.de> wrote:
>
>
> On 19/06/14 13:59, Andrew Fish wrote:
>
>
> On Jun 19, 2014, at 11:58 AM, e...@ragequ.it wrote:
>
>
> I changed the `retf` to a `ret` to get it to assemble for now.
>
>
> That looks right. I think it should be ret.
> i'm pretty certain this should be lret. Basically either the osx assembler
> should support retf(which I have a patch for, but probably won't happen ever)
> or it should use lret, which is exactly the same instruction.
>
>
> Well the code looked like this? So I assumed they did not mean iret
> .byte 0x48 # prefix to composite "retq" with next "retf"
> retf # far return
> DoIret:
> iretq
>
>
> I think the code is trying to generate this.
>
> 48 cb rex.W retf
> It looks like this is used for SMM.
>
>
>
>
>
>
>
>
> Issue #2
>
> Next issue is with the ACPI tables:
>
> Issue #3
> Try changing your *_*_*_ASLDLINK_FLAGS in Conf/tools_def.txt to look like:
> -e _ReferenceAcpiTable -preload -segalign 0x20 -pie -seg1addr 0x240
> -read_only_relocs suppress -map $(DEST_DIR_DEBUG)/$(BASE_NAME).map
> the link_flags look fine, but it's like that you have a newer iasl therefore
> the cc and pp flags might need adjustment as well.
>
> *_ASLCC_FLAGS = -x c -save-temps -g -O0 -fshort-wchar
> -fno-strict-aliasing -Wall -Werror -Wno-missing-braces -c -include AutoGen.h
> *_ASLPP_FLAGS = -x c -E -P
>
>
>
>
> No. The library has non PC relative addressing in it and this is not
> supported by the linker. When building the UefiCpuPkg.dsc this library is
> built, but not linked so you don’t hit this error building the package. Just
> linking the library.
>
> So things like:
> movabsq ASM_PFX(mDoFarReturnFlag), %ax
>
> Need to be:
> movzbl ASM_PFX(mDoFarReturnFlag)(%rip), %eax
>
> You need to convert any assembly code using absolute addresses to to relative
> addressing.
> I gave up at this point. This is a major PITA. At this point my recommendation
> is to make a gcc 48 efi cross compiler. Andrew gave me some help for these
> too, but I don't think it's worth exploring.
>
> Even if you manage to this to compile somehow the emulator will crash. At
> least it did for me.
>
>
> Sounds like a bug some place in the assembly.
>
>
> Basically the osx linker does not support PIE(amongst other things).
>
>
> So why do we care? It supports a flavor of PIC, so PIE is just an
> optimization, and clang is very good at optimization. For the 99% of the code
> that is C it is a don’t care.
>
> The issue is the lack of relocation support, so folks keep writing
> non-PIC/non-PIE assembly code that maps into PE/COFF relocations. This is
> what causes the linker failures.
> The clang assembler is also pickier about syntax.
>
> Thanks,
>
> Andrew Fish
>
>
> You can build an efi cross compiler with the code available here:
>
> https://github.com/STLVNUB/CloverGrower
>
> personally I modified the script for easier and stripped down use. If you want
> I'll up the fork when I have time, (which won't be until next thursday)
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems_______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
> <ExceptionHandlerAsm.S.patch>------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems_______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
