Replies: 2 comments 1 reply
-
On Jan 16, 2023, at 7:30 AM, 阴天 ***@***.***> wrote:
I want to use this GNU feature to support dynamic initialization of global variables before entering functions. But I found that this feature does not seem to have an effect, I run the compiled EFI program only my entry function prints the log, and the function I decorate with attribute((constructor)) does not print the log. I wonder if I need to add or remove some compilation option to activate the attribute (constructor) feature. Or is there a library in edk2 that provides related functionality?
We don’t support __attribute__(construtor) in edk2 as it is a GNU specific extension and in general we support a wide range of compilers so we try very hard not to use things that don’t work in all place. Not to mention __attribute__(construtor) is likely tied in to how dynamic libraries work in Linux so not only does it require support from the C lib, but also likely it implies magic sections in ELF etc.
The edk2 style libraries already support automatically calling constructors and destructors so in general you should just be able to do that. You just add entries in the [Defines] section of the library INF (build config file) file. So you just add CONSTRUCTOR/DESTRUCTOR = Name of C function. The edk2 build system will auto generate code to call all the library constructors and destructors in the order of their build dependencies.
Here is an example library:
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
You can search for other examples via[]:
/Volumes/Case/edk2(master)>git grep DESTRUCTOR -- \*.inf
DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/AcpiDbg2LibArm.inf:17: DESTRUCTOR = AcpiDbg2LibDestructor
DynamicTablesPkg/Library/Acpi/Arm/AcpiFadtLibArm/AcpiFadtLibArm.inf:17: DESTRUCTOR = AcpiFadtLibDestructor
DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/AcpiGtdtLibArm.inf:17: DESTRUCTOR = AcpiGtdtLibDestructor
DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/AcpiIortLibArm.inf:17: DESTRUCTOR = AcpiIortLibDestructor
...
So you might be better off asking what problem you are trying to solve.
Thanks,
Andrew Fish
… —
Reply to this email directly, view it on GitHub <#3905>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD4ZCO3VVCITG7VOISIZB3LWSVSTFANCNFSM6AAAAAAT437UZY>.
You are receiving this because you are subscribed to this thread.
|
Beta Was this translation helpful? Give feedback.
1 reply
-
On Jan 21, 2023, at 11:19 PM, 阴天 ***@***.***> wrote:
Thanks for the answer, I know that constructors and destructors can be set in INF files, but this feature is not so suitable for me. My requirement is not dependent on Linux, which is very common in embedded development, and I think EDK2 is very similar to embedded bare metal programs, so I think my idea may be achievable.
Those projects likely assume only one compiler and implement compiler specific code. The edk2 supports VC++, clang, GCC, and other compilers, so it is quite hard to add compiler specific features for features that don’t exist in all the compilers.
The other issue is EFI defines the image format as PE/COFF so any kind of an ELF does this just adds lots of complexity. The compiler may not support that feature if it produces PE/COFF, or our ELF to PE/COFF converter may not do the right thing.
If this was just gcc with ELF binaries I’d say just write the code to parse the image sections end up in as that is likely what the other embedded projects do. For non edk2 embedded projects it is not uncommon to play around a lot with image sections. We generally don’t need to do that for edk2 as the early code gets inserted into a Firmware Volume that is defined in the PI Industry standard. So you can just use normal PE/COFF executables without extra embedded magic.
I ported a GUI library to edk2, and I hope that each function can be written in different .c files during development, which is convenient for later maintenance upgrades.
The attribute (constructor) I mentioned can solve my needs, including the attribute I learned later (section(name)) This can also solve my needs, but I need to change the link script, I am afraid that this will change to the design of edk2 itself, so section I haven't tried it yet.
I just need a piece of memory space for me to store the list of initialization functions, and I can register the initialization function in this memory in the new .c file, my main function only needs to iterate through the execution of the initialization function saved in the memory, and the main function does not need to be changed in the future. Is there any way I can achieve this in EDK2?
The closest pattern I can think of in edk2 is a NULL library (a library class that always gets linked) that publish a constructor and destructor function. Then the distributed code calls the common library functions to register the functions.
Thanks,
Andrew Fish
… —
Reply to this email directly, view it on GitHub <#3905 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD4ZCO6R7YOGDCIU6OUDXYDWTTNOXANCNFSM6AAAAAAT437UZY>.
You are receiving this because you commented.
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I want to use this GNU feature to support dynamic initialization of global variables before entering functions. But I found that this feature does not seem to have an effect, I run the compiled EFI program only my entry function prints the log, and the function I decorate with attribute((constructor)) does not print the log. I wonder if I need to add or remove some compilation option to activate the attribute (constructor) feature. Or is there a library in edk2 that provides related functionality?
Beta Was this translation helpful? Give feedback.
All reactions