Revision as of 15:02, 20 November 2015 view source osdev>Intx13 →‎Using GNU toolchain for compiling and debugging EFI applications ← Older edit		Revision as of 15:07, 20 November 2015 view source osdev>Intx13 More reorganization Newer edit →
Line 591: We need to unload executable binary by "file" command after sections layout is displayed because otherwise its symbols will override debug symbols loaded by "add-symbol-file" command (at least for data section). You do not need to load it each time because sections addresses will change only after next recompilation. Alternatively "objdump" utility can be used to dump sections. As you can see after setup is done you can normally debug your application using whole power of the GDB. Set your "wait" variable to zero and you will exit from endless loop. Set breakpoints/watchpoints, continue execution, enjoy debugging! == Binary Format ==▼ == UEFI applications in detail == ▲=== Binary Format === (U)EFI generally uses the PE-executable format, with its very own subtypes. Every (U)EFI application is basically a DLL without symbol tables et al, and another subtypes: Line 599 ⟶ 600: * (U)EFI run-time driver (12). === Calling Conventions === The EFI specifications specify the calling conventions for 32-bit 80x86 and Itanium. The (later) UEFI specifications define the calling conventions for 32-bit 80x86, Itanium and 64-bit 80x86 Line 607: For 64-bit 80x86, Microsoft's x64 calling convention is used. This calling convention requires the stack be aligned on a 16-byte boundary (from the callee's perspective), and that a 32-byte "shadow space" be reserved on the stack (immediately above the return RIP). The shadow space is not described by the UEFI specifications. This can lead to frustrated assembly language programmers (who are writing code based on the UEFI specifications alone and don't know about the shadow space, and therefore waste '''hours''' trying to figure out why their stack gets trashed by some EFI functions). === ~~Example~~Language ~~in C~~binding === TODO ~~Below is an example of an EFI application written in C that displays: "Hello World".~~ ~~<source lang="c">~~ ~~#include <efi.h>~~ ~~#include <efilib.h>~~ ~~EFI_STATUS efi_main(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE SystemTable)~~ { ~~SIMPLE_TEXT_OUTPUT_INTERFACE conout;~~ ~~InitializeLib(ImageHandle, SystemTable);~~ ~~conout = SystemTable->ConOut;~~ ~~uefi_call_wrapper(conout->OutputString, 2, conout, (CHAR16 )L"Hello World\n\r");~~ ~~return EFI_SUCCESS;~~ } ~~</source>~~ == Example in FASM == Line 685 ⟶ 667: section '.reloc' fixups data discardable </source> === EFI Byte Code=== TODO == Common Problems == === My ~~bootloader~~UEFI application hangs/resets after about 5 minutes === When control is handed to your ~~EFI~~UEFI application by ~~the~~ firmware ~~boot manager~~, it sets a watchdog timer for 5 minutes, after which the firmware is reinvoked as it assumes your application has hung. The firmware in this case will normally try to reset the system (although the OVMF firmware in VirtualBox simply causes the screen to go black and hang). To counteract this, you are required to refresh the watchdog timer before it times out. Alternatively, you can disable it completely with code like <source lang="C">BS->SetWatchdogTimer(0, 0, 0, NULL);</source>Obviously this is not a problem for most bootloaders, but can cause an issue if you have an interactive loader which waits for user input. Also note that you are required to disable the watchdog timer if you exit back to the firmware. === My bootloader hangs if I use user defined EFI_MEMORY_TYPE values === Line 697 ⟶ 683: == See also == === OSDEV === [[UEFI Bare Bones]] * [[PE]] file format === Wikipedia ===

UEFI: Difference between revisions