Status Update

[Eric McCorkle]

This report is largely on activities from the beginning of last week. 
Towards the end, I was occupied with job interviews and things related 
to that, so I was unable to do much work.

I was able to identify the root cause as to why I could not get a Hello, 
World type application to run.  The problem is that when compiling on an 
amd64 machine, <stdint.h> defines __uint64_t as unsigned long.  When 
cross-compiling to i386 with the -m32 flag, this means that __uint64_t 
is incorrectly defined to be 32 bits in size.  The result is that the 
EFI_SYSTEM_TABLE structure was misaligned.  On a mingw32 build (like 
what EDK does), this isn't a problem, as it's using the i386 headers.

I will still aim to create EDK II and IASL ports if I have the time, or 
after the end of summer if I run out.

As things stand now, I can build a hello world type application.  When I 
try to tie it in with libefi, however, things no longer work, but I know 
why.  The process for starting up loader.efi is as follows: first, 
_start gets called, which subsequently calls _reloc, then efi_main.  In 
libefi, efi_main does some initialization, then calls main.  At present, 
when I try to build experimental applications that start with main (as 
opposed to defining their own efi_main and not linking against 
libefi.a), _reloc appears to fail.  I am going to contact Rui Paulo to 
learn more about _reloc and what its purpose is.

Also, loader.efi still doesn't run.  There are several possible reasons 
for this.  First, something somewhere might use __uint64_t, and I've 
only added macros to properly define UINT64.  Second, I also noticed 
that mingw32 appears to reserve 8 bytes of stack space that seem to be 
unused, but may be an essential part of the ABI.  The native build does 
not reserve that space.


On a personal note, I will be traveling in the coming week, so my 
contact may be intermittent.  However, I should be able to get work done.