On 08/12/15 20:57, Ard Biesheuvel wrote:
> After the recent GNU linker script changes, the following warning is
> emitted many times during the OVMF/X86 build:
>
> BFD: <...>: warning: Empty loadable segment detected, is this intentional ?
>
> This is caused by the fact that, now that the section layout has changed
> somewhat, the .eh_frame section is assigned an ELF segment of its own,
> which ends up with no contents at all after we strip the .eh_frame
> section from the output.
I tried to make sure that I understand this right. I picked a random executable
(Build/OvmfIa32/DEBUG_GCC48/IA32/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe/DEBUG/AcpiPlatform.*)
and I compared the output of
readelf --section-headers --program-headers AcpiPlatform.debug
vs.
readelf --section-headers --program-headers AcpiPlatform.dll
Pre-patch, the difference is:
> --- AcpiPlatform.debug.readelf 2015-08-12 21:41:44.903567060 +0200
> +++ AcpiPlatform.dll.readelf 2015-08-12 21:41:58.262643152 +0200
> @@ -1,28 +1,15 @@
> -There are 21 section headers, starting at offset 0x43210:
> +There are 8 section headers, starting at offset 0x6ea0:
>
> Section Headers:
> [Nr] Name Type Addr Off Size ES Flg Lk
> Inf Al
> [ 0] NULL 00000000 000000 000000 00 0
> 0 0
> [ 1] .text PROGBITS 00000220 0000a0 006dac 00 AX 0
> 0 32
> - [ 2] .rel.text REL 00000000 0451fc 001ed0 08 19
> 1 4
> + [ 2] .rel.text REL 00000000 0082ec 001ed0 08 6
> 1 4
> [ 3] .data NOBITS 00006fe0 006e4c 000028 00 WA 0
> 0 32
> - [ 4] .eh_frame PROGBITS 00007020 006e4c 000e9c 00 A 0
> 0 4
> - [ 5] .rel.eh_frame REL 00000000 0470cc 000ca0 08 19
> 4 4
> - [ 6] .debug_info PROGBITS 00000000 007ce8 02145f 00 0
> 0 1
> - [ 7] .rel.debug_info REL 00000000 047d6c 011ca8 08 19
> 6 4
> - [ 8] .debug_abbrev PROGBITS 00000000 029147 004145 00 0
> 0 1
> - [ 9] .debug_loc PROGBITS 00000000 02d28c 004b9a 00 0
> 0 1
> - [10] .rel.debug_loc REL 00000000 059a14 0052f0 08 19
> 9 4
> - [11] .debug_aranges PROGBITS 00000000 031e26 001078 00 0
> 0 1
> - [12] .rel.debug_arange REL 00000000 05ed04 000de8 08 19
> 11 4
> - [13] .debug_ranges PROGBITS 00000000 032e9e 000ed8 00 0
> 0 1
> - [14] .rel.debug_ranges REL 00000000 05faec 001a90 08 19
> 13 4
> - [15] .debug_line PROGBITS 00000000 033d76 0087b4 00 0
> 0 1
> - [16] .rel.debug_line REL 00000000 06157c 000ca0 08 19
> 15 4
> - [17] .debug_str PROGBITS 00000000 03c52a 006c3d 01 MS 0
> 0 1
> - [18] .shstrtab STRTAB 00000000 043167 0000a6 00 0
> 0 1
> - [19] .symtab SYMTAB 00000000 043558 000d40 10 20
> 80 4
> - [20] .strtab STRTAB 00000000 044298 000f63 00 0
> 0 1
> + [ 4] .gnu_debuglink PROGBITS 00000000 006e4c 000018 00 0
> 0 1
> + [ 5] .shstrtab STRTAB 00000000 006e64 00003a 00 0
> 0 1
> + [ 6] .symtab SYMTAB 00000000 006fe0 000860 10 7
> 4 4
> + [ 7] .strtab STRTAB 00000000 007840 000aa9 00 0
> 0 1
> Key to Flags:
> W (write), A (alloc), X (execute), M (merge), S (strings)
> I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
> @@ -35,11 +22,11 @@
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> LOAD 0x0000a0 0x00000220 0x00000220 0x06dac 0x06de8 RWE 0x20
> - LOAD 0x006e4c 0x00007020 0x00007020 0x00e9c 0x00e9c R 0x4
> - GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x10
> + LOAD 0x006e4c 0x00000000 0x00000000 0x00000 0x00000 R 0x4
> + GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
>
> Section to Segment mapping:
> Segment Sections...
> 00 .text .data
> - 01 .eh_frame
> + 01
> 02
The .eh_frame section is removed, but segment 01 remains in place (without
.eh_frame being mapped to it).
> (Note that the program headers that contain the
> segment information are completely irrelevant to us since the PE/COFF
> conversion does not rely on them.)
>
> Since we only retain the .eh_frame data for external debugging, and not
> for things like stack unwinding or generating backtraces at runtime, we
> can remedy the situation by passing -fno-asynchronous-unwind-tables on
> the GCC command line. This option instructs the compiler to emit the
> unwind data into a debug section called .debug_frame instead of into
> .eh_frame.
Post patch, the difference between .debug and .dll is limited to the Section
Headers; there is no difference between the Program Headers of each (nor the
Section to Segment mapping of each). Those are
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000080 0x00000220 0x00000220 0x06dac 0x06de8 RWE 0x20
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x10
Section to Segment mapping:
Segment Sections...
00 .text .data
01
in both now.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
> ---
> BaseTools/Conf/tools_def.template | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/BaseTools/Conf/tools_def.template
> b/BaseTools/Conf/tools_def.template
> index 6e2d4909b9fc..0df9b51d95fb 100644
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -3840,7 +3840,7 @@ DEFINE GCC_AARCH64_RC_FLAGS = -I binary -O
> elf64-littleaarch64 -B aarch64
>
> DEFINE GCC44_ALL_CC_FLAGS = -g -fshort-wchar -fno-strict-aliasing
> -Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -c
> -include AutoGen.h -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
> DEFINE GCC44_IA32_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -m32
> -malign-double -fno-stack-protector -D EFI32
> -DEFINE GCC44_X64_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -m64
> -fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -DNO_BUILTIN_VA_FUNCS
> -mno-red-zone -Wno-address -mcmodel=large
> +DEFINE GCC44_X64_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -m64
> -fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -DNO_BUILTIN_VA_FUNCS
> -mno-red-zone -Wno-address -mcmodel=large -fno-asynchronous-unwind-tables
> DEFINE GCC44_IA32_X64_DLINK_COMMON = -nostdlib -n -q --gc-sections -z
> common-page-size=0x20
> DEFINE GCC44_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_COMMON)
> --entry ReferenceAcpiTable -u ReferenceAcpiTable
> DEFINE GCC44_IA32_X64_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_COMMON)
> --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map
> $(DEST_DIR_DEBUG)/$(BASE_NAME).map
>
I think the patch is sound (see also Leif's commit 28e80bef), but it's not
complete: the same issue exists for IA32. So I modified GCC44_IA32_CC_FLAGS
similarly, just for build-testing the OvmfPkgIa32.dsc platform, and the flag
works for that too.
Please include the GCC44_IA32_CC_FLAGS change as well, and repost with:
Reviewed-by: Laszlo Ersek <ler...@redhat.com>
Build-tested-by: Laszlo Ersek <ler...@redhat.com>
Thank you!
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
