Related to: https://bugzilla.tianocore.org/show_bug.cgi?id=556 PE/COFF images generally use .rdata sections, while ELF and Mach-O images generally use .rodata segments. Latter two may be converted into former as part of the build process. To more easily ensure permission consistency, and to optimise image size, only one should be used consistently throughout EDK II. Currently, e.g. by using the CLANGPDB toolchain, e.g. CpuDxe may have both sections due to .rdata generated by the compiler and .rodata imported from BaseUefiCpuLib[1]. [1] https://github.com/tianocore/edk2/blob/2072c22a0d63c780b0cc6377f6d4ffb116ad6144/UefiCpuPkg/Library/BaseUefiCpuLib/X64/InitializeFpu.nasm#L9
Marvin, you can continue to provide the proposal.
The easiest solution would be to move the problematic data declarations from ASM to C files. While sometimes this might be inconvenient as there is no appropriate C file already present, I think think this is a rare case and also believe less ASM is almost always a good idea. The compiler would then consistently choose .rdata or .rodata. Any obligations?
See also: 5b78f30d81d7 ("UefiCpuPkg/BaseUefiCpuLib: Use NASM read-only data section name", 2017-05-19) I agree that moving the read-only data definitions to C is a tolerable compromise. Not great, but given the range of compilers we seek to support, it should be OK.
In fact, it seems like ".rodata" confuses the PE toolchains as well (CLANGPDB in this instance): Section - '.rodata ' VirtualSize - 0x00000006 VirtualAddress - 0x00010000 SizeOfRawData - 0x00001000 PointerToRawData - 0x00010000 PointerToRelocations - 0x00000000 PointerToLinenumbers - 0x00000000 NumberOfRelocations - 0x00000000 NumberOfLinenumbers - 0x00000000 Characteristics - 0x60000020 Characteristics = 0x60000020 = EFI_IMAGE_SCN_CNT_CODE | EFI_IMAGE_SCN_MEM_EXECUTE | EFI_IMAGE_SCN_MEM_READ
Actually, I forgot that we can use preprocessor definitions in NASM. This makes this a far simpler matter of: "SECTION RO_DATA_SECTION_NAME" in NASM "RELEASE_VS2019_X64_NASM_FLAGS = -Ox -f win64 -DRO_DATA_SECTION_NAME=.rdata"; "*_XCODE5_X64_NASM_FLAGS = -f macho64 -DRO_DATA_SECTION_NAME=.rodata"; "*_CLANGPDB_X64_NASM_FLAGS = -f win64 -DRO_DATA_SECTION_NAME=.rodata"; [...] in tools_def.template However, I also noticed that ELF-based toolchains (GCC5, CLANG38) merge ".rodata" into ".text", PE toolchains (VS2019, CLANGPDB) however generate a separate ".rdata" section. Should this be made consistent?
