gnu-efi/lib/entry.c

74 lines
1.8 KiB
C
Raw Normal View History

Make ELF constructors and destructors work This makes setup and teardown functions defined with __attribute__((__constructor__) and __attribute__((__destructor__)) work in normal circumstances in EFI binaries. A couple of notes: - it implements both the old-style .ctors/.dtors methods and the newer style .init_array/.fini_array ELF constructor and destructor arrays, processed in the order: .init_array[] .ctors[] efi_main() .dtors[] .fini_array[] - Destructors will only be called if efi_main() exits using "return"; any call to Exit() will still longjmp() past them. - InitializeLib() has already been called before constructors run, so they don't need to call it (and neither does anything else.) For compatibility, it has been altered so calling it more than once is safe. - No attempt is made to handle any constructor or destructor with a prototype other than "void func(void);", but note that InitializeLib has been called, so LibImageHandle, ST, BS, and RT are set. - The init_array/ctor/dtor/fini_array lists aren't the using the GNU "CONSTRUCTOR" output section command, so they don't start with a size. - The lists are individually sorted during the link stage via SORT_BY_NAME() in the linker script. - The default (empty) init_array/ctor/dtor/fini_array lists are padded out to 8-byte alignment with ".p2align 3, 0", and each list always has at least one ".long 0" at the end of it (even if it's completely empty). As a result, they can have NULLs that need to be skipped. The sections they're in are mergeable, so the NULLs don't have to be exclusively at the end. - The ia64 and mips64el arches have not been tested. Signed-off-by: Peter Jones <pjones@redhat.com>
2023-03-28 15:28:40 +03:00
/*
* ctors.c
* Copyright 2019 Peter Jones <pjones@redhat.com>
*
*/
#include <efi.h>
#include <efilib.h>
typedef void (*funcp)(void);
Make ELF constructors and destructors work This makes setup and teardown functions defined with __attribute__((__constructor__) and __attribute__((__destructor__)) work in normal circumstances in EFI binaries. A couple of notes: - it implements both the old-style .ctors/.dtors methods and the newer style .init_array/.fini_array ELF constructor and destructor arrays, processed in the order: .init_array[] .ctors[] efi_main() .dtors[] .fini_array[] - Destructors will only be called if efi_main() exits using "return"; any call to Exit() will still longjmp() past them. - InitializeLib() has already been called before constructors run, so they don't need to call it (and neither does anything else.) For compatibility, it has been altered so calling it more than once is safe. - No attempt is made to handle any constructor or destructor with a prototype other than "void func(void);", but note that InitializeLib has been called, so LibImageHandle, ST, BS, and RT are set. - The init_array/ctor/dtor/fini_array lists aren't the using the GNU "CONSTRUCTOR" output section command, so they don't start with a size. - The lists are individually sorted during the link stage via SORT_BY_NAME() in the linker script. - The default (empty) init_array/ctor/dtor/fini_array lists are padded out to 8-byte alignment with ".p2align 3, 0", and each list always has at least one ".long 0" at the end of it (even if it's completely empty). As a result, they can have NULLs that need to be skipped. The sections they're in are mergeable, so the NULLs don't have to be exclusively at the end. - The ia64 and mips64el arches have not been tested. Signed-off-by: Peter Jones <pjones@redhat.com>
2023-03-28 15:28:40 +03:00
/*
* Note that these aren't the using the GNU "CONSTRUCTOR" output section
* command, so they don't start with a size. Because of p2align and the
* end/END definitions, and the fact that they're mergeable, they can also
* have NULLs which aren't guaranteed to be at the end.
*/
extern funcp __init_array_start[], __init_array_end[];
extern funcp __CTOR_LIST__[], __CTOR_END__[];
extern funcp __fini_array_start[], __fini_array_end[];
extern funcp __DTOR_LIST__[], __DTOR_END__[];
Make ELF constructors and destructors work This makes setup and teardown functions defined with __attribute__((__constructor__) and __attribute__((__destructor__)) work in normal circumstances in EFI binaries. A couple of notes: - it implements both the old-style .ctors/.dtors methods and the newer style .init_array/.fini_array ELF constructor and destructor arrays, processed in the order: .init_array[] .ctors[] efi_main() .dtors[] .fini_array[] - Destructors will only be called if efi_main() exits using "return"; any call to Exit() will still longjmp() past them. - InitializeLib() has already been called before constructors run, so they don't need to call it (and neither does anything else.) For compatibility, it has been altered so calling it more than once is safe. - No attempt is made to handle any constructor or destructor with a prototype other than "void func(void);", but note that InitializeLib has been called, so LibImageHandle, ST, BS, and RT are set. - The init_array/ctor/dtor/fini_array lists aren't the using the GNU "CONSTRUCTOR" output section command, so they don't start with a size. - The lists are individually sorted during the link stage via SORT_BY_NAME() in the linker script. - The default (empty) init_array/ctor/dtor/fini_array lists are padded out to 8-byte alignment with ".p2align 3, 0", and each list always has at least one ".long 0" at the end of it (even if it's completely empty). As a result, they can have NULLs that need to be skipped. The sections they're in are mergeable, so the NULLs don't have to be exclusively at the end. - The ia64 and mips64el arches have not been tested. Signed-off-by: Peter Jones <pjones@redhat.com>
2023-03-28 15:28:40 +03:00
static void ctors(void)
{
size_t __init_array_length = __init_array_end - __init_array_start;
for (size_t i = 0; i < __init_array_length; i++) {
funcp func = __init_array_start[i];
if (func != NULL)
Make ELF constructors and destructors work This makes setup and teardown functions defined with __attribute__((__constructor__) and __attribute__((__destructor__)) work in normal circumstances in EFI binaries. A couple of notes: - it implements both the old-style .ctors/.dtors methods and the newer style .init_array/.fini_array ELF constructor and destructor arrays, processed in the order: .init_array[] .ctors[] efi_main() .dtors[] .fini_array[] - Destructors will only be called if efi_main() exits using "return"; any call to Exit() will still longjmp() past them. - InitializeLib() has already been called before constructors run, so they don't need to call it (and neither does anything else.) For compatibility, it has been altered so calling it more than once is safe. - No attempt is made to handle any constructor or destructor with a prototype other than "void func(void);", but note that InitializeLib has been called, so LibImageHandle, ST, BS, and RT are set. - The init_array/ctor/dtor/fini_array lists aren't the using the GNU "CONSTRUCTOR" output section command, so they don't start with a size. - The lists are individually sorted during the link stage via SORT_BY_NAME() in the linker script. - The default (empty) init_array/ctor/dtor/fini_array lists are padded out to 8-byte alignment with ".p2align 3, 0", and each list always has at least one ".long 0" at the end of it (even if it's completely empty). As a result, they can have NULLs that need to be skipped. The sections they're in are mergeable, so the NULLs don't have to be exclusively at the end. - The ia64 and mips64el arches have not been tested. Signed-off-by: Peter Jones <pjones@redhat.com>
2023-03-28 15:28:40 +03:00
func();
}
size_t __CTOR_length = __CTOR_END__ - __CTOR_LIST__;
for (size_t i = 0; i < __CTOR_length; i++) {
size_t current = __CTOR_length - i - 1;
funcp func = __CTOR_LIST__[current];
if (func != NULL)
Make ELF constructors and destructors work This makes setup and teardown functions defined with __attribute__((__constructor__) and __attribute__((__destructor__)) work in normal circumstances in EFI binaries. A couple of notes: - it implements both the old-style .ctors/.dtors methods and the newer style .init_array/.fini_array ELF constructor and destructor arrays, processed in the order: .init_array[] .ctors[] efi_main() .dtors[] .fini_array[] - Destructors will only be called if efi_main() exits using "return"; any call to Exit() will still longjmp() past them. - InitializeLib() has already been called before constructors run, so they don't need to call it (and neither does anything else.) For compatibility, it has been altered so calling it more than once is safe. - No attempt is made to handle any constructor or destructor with a prototype other than "void func(void);", but note that InitializeLib has been called, so LibImageHandle, ST, BS, and RT are set. - The init_array/ctor/dtor/fini_array lists aren't the using the GNU "CONSTRUCTOR" output section command, so they don't start with a size. - The lists are individually sorted during the link stage via SORT_BY_NAME() in the linker script. - The default (empty) init_array/ctor/dtor/fini_array lists are padded out to 8-byte alignment with ".p2align 3, 0", and each list always has at least one ".long 0" at the end of it (even if it's completely empty). As a result, they can have NULLs that need to be skipped. The sections they're in are mergeable, so the NULLs don't have to be exclusively at the end. - The ia64 and mips64el arches have not been tested. Signed-off-by: Peter Jones <pjones@redhat.com>
2023-03-28 15:28:40 +03:00
func();
}
}
static void dtors(void)
{
size_t __DTOR_length = __DTOR_END__ - __DTOR_LIST__;
for (size_t i = 0; i < __DTOR_length; i++) {
funcp func = __DTOR_LIST__[i];
if (func != NULL)
Make ELF constructors and destructors work This makes setup and teardown functions defined with __attribute__((__constructor__) and __attribute__((__destructor__)) work in normal circumstances in EFI binaries. A couple of notes: - it implements both the old-style .ctors/.dtors methods and the newer style .init_array/.fini_array ELF constructor and destructor arrays, processed in the order: .init_array[] .ctors[] efi_main() .dtors[] .fini_array[] - Destructors will only be called if efi_main() exits using "return"; any call to Exit() will still longjmp() past them. - InitializeLib() has already been called before constructors run, so they don't need to call it (and neither does anything else.) For compatibility, it has been altered so calling it more than once is safe. - No attempt is made to handle any constructor or destructor with a prototype other than "void func(void);", but note that InitializeLib has been called, so LibImageHandle, ST, BS, and RT are set. - The init_array/ctor/dtor/fini_array lists aren't the using the GNU "CONSTRUCTOR" output section command, so they don't start with a size. - The lists are individually sorted during the link stage via SORT_BY_NAME() in the linker script. - The default (empty) init_array/ctor/dtor/fini_array lists are padded out to 8-byte alignment with ".p2align 3, 0", and each list always has at least one ".long 0" at the end of it (even if it's completely empty). As a result, they can have NULLs that need to be skipped. The sections they're in are mergeable, so the NULLs don't have to be exclusively at the end. - The ia64 and mips64el arches have not been tested. Signed-off-by: Peter Jones <pjones@redhat.com>
2023-03-28 15:28:40 +03:00
func();
}
size_t __fini_array_length = __fini_array_end - __fini_array_start;
for (size_t i = 0; i < __fini_array_length; i++) {
size_t current = __fini_array_length - i - 1;
funcp func = __fini_array_start[current];
if (func != NULL)
Make ELF constructors and destructors work This makes setup and teardown functions defined with __attribute__((__constructor__) and __attribute__((__destructor__)) work in normal circumstances in EFI binaries. A couple of notes: - it implements both the old-style .ctors/.dtors methods and the newer style .init_array/.fini_array ELF constructor and destructor arrays, processed in the order: .init_array[] .ctors[] efi_main() .dtors[] .fini_array[] - Destructors will only be called if efi_main() exits using "return"; any call to Exit() will still longjmp() past them. - InitializeLib() has already been called before constructors run, so they don't need to call it (and neither does anything else.) For compatibility, it has been altered so calling it more than once is safe. - No attempt is made to handle any constructor or destructor with a prototype other than "void func(void);", but note that InitializeLib has been called, so LibImageHandle, ST, BS, and RT are set. - The init_array/ctor/dtor/fini_array lists aren't the using the GNU "CONSTRUCTOR" output section command, so they don't start with a size. - The lists are individually sorted during the link stage via SORT_BY_NAME() in the linker script. - The default (empty) init_array/ctor/dtor/fini_array lists are padded out to 8-byte alignment with ".p2align 3, 0", and each list always has at least one ".long 0" at the end of it (even if it's completely empty). As a result, they can have NULLs that need to be skipped. The sections they're in are mergeable, so the NULLs don't have to be exclusively at the end. - The ia64 and mips64el arches have not been tested. Signed-off-by: Peter Jones <pjones@redhat.com>
2023-03-28 15:28:40 +03:00
func();
}
}
extern EFI_STATUS efi_main(EFI_HANDLE image, EFI_SYSTEM_TABLE *systab);
EFI_STATUS _entry(EFI_HANDLE image, EFI_SYSTEM_TABLE *systab)
{
EFI_STATUS status;
InitializeLib(image, systab);
ctors();
status = efi_main(image, systab);
dtors();
return status;
}
// vim:fenc=utf-8:tw=75:noet