On Jun 19, 2014, at 3:06 PM, Reza Jelveh <reza.jel...@tuhh.de> wrote:
> 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
>
IRET pops PC and EFLAGS. So a Hardware Interrupt handler (exception handler)
uses IRET, and the hardware has spilled the EFLAGS on the stack in addition to
the PC (it is more complicated that this due to extra stuff that also gets
spilled, but that does not matter for IRET, just the interrupt handler).
RETF pops PC and CS, which means it allows you to change segments (must have
something to do with why it is needed in SMM?).
So they are not the same, and the code above generates different instructions.
48 cb rex.W retf
vs.
48 cf rex.W iret
> 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
>
This example is about LRET and RETF, not IRET? So it seems to be about
assembler name aliases, not processor instructions?
For example iretq is really assembler shorthand for:
48 cf rex.W iret
So for the processor it is a prefix instruction and the old IRET instruction,
the assembler is making up a short hand to hide the prefix byte.
>>
>> 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.
>
Building compilers != building firmware, but contributions are always welcome.
We tried hard to avoid unneeded assembler in edk2, but things like exception
handlers need to be written in assembler.
I think AsmGetTemplateAddressMap and AsmVectorNumFixup could have probably been
written in C, but the CommonInterruptEntry has to be written in assembly.
Thanks,
Andrew Fish
------------------------------------------------------------------------------
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
