Calling own function results in an crash

Question

I try to write a simple start uefi program for my kernel, but I have a problem linking everything together.

I want to call functions defined in my header files but this results in my uefi application to crash. (After the intended call the following print statements are not executed so I assume an crash.) I use gnu-efi but I am not sure if I am doing something gnu-efi specific or uefi general wrong. Everything compiles without warnings or errors and removing the "problem-function" causes the program to work (I can execute my efi file and the print statements work).

My main.c file:

#include "gnu-efi/inc/efi.h"
#include "gnu-efi/inc/efilib.h"
#include <inttypes.h>
#include "conversion.h"

EFI_STATUS
EFIAPI
efi_main(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) {

   InitializeLib(ImageHandle, SystemTable);
   CONVSTRING(numstr) = L"00000000000000000000";
   ui64str(numstr, 5);   //The line causing the problem
   Print(L"Hello, world!\n");
   Print(numstr);
   Print(L"\n");
   
   return EFI_SUCCESS;
}

My conversion.h file:

#include "gnu-efi/inc/efi.h"
#include<inttypes.h>

#define CONVSTRING(name) CHAR16 name[21]

// String has to be the length of 21
void ui64str(CHAR16* string, uint64_t number);

My conversion.c file:

#include<inttypes.h>
#include "gnu-efi/inc/efi.h"
#include "conversion.h"

void ui64str(CHAR16* string, uint64_t number)
{
    // "clear" string
    string = L"00000000000000000000";
    return;
}

(If needed I use a batch-script to build every thing)

gcc main.c                     \
    -c                         \
    -fno-stack-protector       \
    -fpic                      \
    -fshort-wchar              \
    -mno-red-zone              \
    -I gnu-efi/inc             \
    -I gnu-efi/inc/x86_64      \
    -I .                       \
    -DEFI_FUNCTION_WRAPPER     \
    -o tmp/main.o

ld tmp/main.o                                   \
   gnu-efi/x86_64/gnuefi/crt0-efi-x86_64.o      \
   -nostdlib                                    \
   -znocombreloc                                \
   -T gnu-efi/gnuefi/elf_x86_64_efi.lds         \
   -shared                                      \
   -Bsymbolic                                   \
   -L gnu-efi/lib                               \
   gnu-efi/x86_64/gnuefi/libgnuefi.a            \
   gnu-efi/x86_64/lib/libefi.a                  \
   -o tmp/main.so

objcopy -j .text                \
        -j .sdata               \
        -j .data                \
        -j .dynamic             \
        -j .dynsym              \
        -j .rel                 \
        -j .rela                \
        -j .reloc               \
        --target=efi-app-x86_64 \
        tmp/main.so             \
        output/BOOTX64.EFI

I don't see `conversion.c` in your build script. Is this a copy-paste omission, or are you indeed not building and linking conversion.c? Remember that a header is enough for a compiler to know declarations and prototypes, but it is not enough for the linker to actually link the definitions into the final binary. — nanofarad, Mar 12 '23 at 16:34
I only used Visual Studio until now and the IDE compiles and links every thing pretty much automatically (the own files). So I had never used the compiler and linker seperatly. — usernameisunavaible, Mar 13 '23 at 13:38

nanofarad · Accepted Answer · 2023-03-12T19:52:30.407

Your build script does not actually build conversion.c into an object file or link it. While you do textually include the header, a header is enough for a compiler to know declarations and prototypes, but it is not enough for the linker to actually link the definitions into the final binary.

Because of the way that you're linking, you never actually get a link-time Unresolved Reference error - ld doesn't mind when compiling with -shared¹, and objcopy doesn't mind the unresolved reference either.

You'll need to ensure that you actually build and link conversion.c. The simplest approach would be to add a second similar gcc command that builds conversion.o from the source in conversion.c, and then add conversion.o to your ld command line.

¹ My instinct (and possibly other readers' instinct) may be to assume that the EFI executable should be statically linked; this page explains the rationale for doing it this way - a shared, relocatable library is built and then objcopy'ed into a final EFI binary. This does seem a tad brittle however.

Calling own function results in an crash

1 Answers1