Content-Type: multipart/alternative; boundary="_000_07E32F241046DA418A0381C1225BFC011A939192E4AUSX7MCPS301A_" --_000_07E32F241046DA418A0381C1225BFC011A939192E4AUSX7MCPS301A_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The calling conventions are detailed here, in case it helps. http://en.wikipedia.org/wiki/X86_calling_conventions From: Jarrod B Johnson [mailto:jbjohnso@us.ibm.com] Sent: Tuesday, August 16, 2011 2:21 PM To: Jarrod B Johnson Cc: elilo-discuss@lists.sourceforge.net Subject: Re: [elilo-discuss] EFI callback workings... Ok, figured it out through careful examination of uefi_call_wrapper and the= assembly that backed it. It wasn't reversed, it was just that the 3rd and 4th arguments happened to = be zero and thus matched RDI and RSI, and gave the appearance of reversed i= f you assume too easily. So in GCC world, we seem to expect the caller to have done rdi, rsi, rdx, r= cx, r8, r9. However, in UEFI world the MS convention is king and so rdi and= rsi are meaningless, rdx and rcx are swapped, and r8 and r9 are in order, = just off by two. Thankfully, I don't need more than 4 arguments to figure o= ut the other magic. Perusing through, I didn't see any documentation or facility for the conver= se of uefi_call_wrapper to rearrange the stack in the way a gcc would work.= Any thoughts? [cid:image001.gif@01CC5C20.3A5B90D0]Jarrod B Johnson---08/16/2011 01:51:25 = PM---So I'm working on implementing support in netfs for IPXE download prot= ocol, if available. From: Jarrod B Johnson/Raleigh/IBM@IBMUS To: elilo-discuss@lists.sourceforge.net Date: 08/16/2011 01:51 PM Subject: [elilo-discuss] EFI callback workings... ________________________________ So I'm working on implementing support in netfs for IPXE download protocol,= if available. The thing I'm hitting is that when iPXE goes to invoke the callback, the ar= gument list seems reversed. I know how to kind of brute force this scenario= , but was wondering if there was some more sane looking way to cope. For example, assume: iPXE calls data callback with: *context, *buffer, length, offset 0xaddf, 0xcdde, 1024, 0 And if I have elilo print out the arguments in order, I get: 0, 1024, 0xcdde, 0xaddf I see quite a bit of dancing in gnu-efi to have code call into uefi provide= d functions, but wasn't clear on the converse...---------------------------= --------------------------------------------------- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ elilo-discuss mailing list elilo-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/elilo-discuss --_000_07E32F241046DA418A0381C1225BFC011A939192E4AUSX7MCPS301A_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

The calling conventions are detailed here, i= n case it helps.

 

http://en.wikipedia.org/wiki/X86_= calling_conventions

 

 

 

From= : Jarrod B Johnson [mailto:jbjohnso@us.ibm.com]
Sent: Tuesday= , August 16, 2011 2:21 PM
To: Jarrod B Johnson
Cc: elil= o-discuss@lists.sourceforge.net
Subject: Re: [elilo-discuss] EFI = callback workings...

=  

Ok, figured it out through careful examination of u= efi_call_wrapper and the assembly that backed it.

It wasn't reversed= , it was just that the 3rd and 4th arguments happened to be zero and thus m= atched RDI and RSI, and gave the appearance of reversed if you assume too e= asily.

So in GCC world, we seem to expect the caller to have done rd= i, rsi, rdx, rcx, r8, r9. However, in UEFI world the MS convention is king = and so rdi and rsi are meaningless, rdx and rcx are swapped, and r8 and r9 = are in order, just off by two. Thankfully, I don't need more than 4 argumen= ts to figure out the other magic.

Perusing through, I didn't see any= documentation or facility for the converse of uefi_call_wrapper to rearran= ge the stack in the way a gcc would work. Any thoughts?

3D"Inactive



<= br>So I'm working on implementing support = in netfs for IPXE download protocol, if available.

The thing I'm hit= ting is that when iPXE goes to invoke the callback, the argument list seems= reversed. I know how to kind of brute force this scenario, but was wonderi= ng if there was some more sane looking way to cope.

For example, ass= ume:
iPXE calls data callback with:
*context, *buffer, length, offset=
0xaddf, 0xcdde, 1024, 0

And if I have elilo print out the argume= nts in order, I get:
0, 1024, 0xcdde, 0xaddf

I see quite a bit of= dancing in gnu-efi to have code call into uefi provided functions, but was= n't clear on the converse...
---= ---------------------------------------------------------------------------=
= uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subv= ersion and
the tools developers use with it. Learn more about = uberSVN and get a free
download at:  http://p.sf.net/sfu/wandisco-dev2dev<= br>_______________________________________________
elilo-di= scuss mailing list
elilo-discuss@lists.sourceforge.net
= = https://lists.sourceforge.net/lists/listinfo/elilo-discuss
<= o:p>

= --_000_07E32F241046DA418A0381C1225BFC011A939192E4AUSX7MCPS301A_--