On 19/06/14 14:51, Andrew Fish wrote: > 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'm not sure what you mean ... retf is lret isn't it? return far, long return here's the binutils patch: http://sourceware.org/ml/binutils/2008-08/msg00270.html and here's the apple cctools patch: https://github.com/fishman/timebomb-gentoo-osx-overlay/blob/master/sys-devel/binutils-apple/files/cctools-839-intel-retf.patch > > 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. sorry, i don't mean to be bitching, but after fiddling with it for a while i decided to go for the pragmatic route. considering this efi stuff is like a "DOS in the bios", I'm actually surprised efi crosscompilers are so badly documented. ------------------------------------------------------------------------------ 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
