> OK. so does that mean we are using a builtin linker script for
> AArch64? That sounds fragile to me ...
Apparently we are using the builtin script. I learned that this can be queried
with the -verbose switch for ld and have attached it. It includes this
interesting alignment mechanism:
/* Adjust the address for the data segment. We want to adjust up to
the same address within the page on the next page up. */
. = ALIGN(CONSTANT (MAXPAGESIZE)) + (. & (CONSTANT (MAXPAGESIZE) - 1));
MAXPAGESIZE doesn't appear to be well documented but I can see patches to ld
that show this being increased to 64KB which is consistent with my objdump
output before the change. So I think this is the "offending" line in the
original script since it shifted data out in ELF even though the PE-COFF
converter packed it tightly, accounting for the section alignment requirements
from ELF.
> Could you please look at the X64 approach, and compare it to yours?
It's really a question for the developer originating -Ttext=0x0 - maybe
Olivier? I don't have the history on how the GCC linker configuration for edk2
came to be.
> Perhaps you could share some numbers or other details to get a feel
> for what exactly goes on here.
I think I described in this in my email titled " AArch64 Debugger Global
Variable Correlation Issues" - I gave the ELF dump showing data shifted out by
64KB. Strangely, this was shifted out not to the next 64KB aligned boundary
but to 0x10000 beyond the last .test/.rodata section - I'm not sure why but
perhaps somebody with more GNU ld experience can figure out why.
Thanks,
Eugene
-----Original Message-----
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Tuesday, June 16, 2015 9:21 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] BaseTools for AArch64 GCC: Ensure that the
correlation .text and .data is consistent between ELF and PE-COFF so the
debugger sees global variables correctly
On 16 June 2015 at 16:50, Cohen, Eugene <eug...@hp.com> wrote:
>> Could you please send patches inline? Attachments are a pain to review.
>
> Sure, I will do that. Because I use Outlook I prefer the attachment since I
> can pull it into a nice patch viewer.
>
I can see how that would be preferred for just viewing, but for
commenting inline it is far from optimal.
>> Applying your patch and doing 'git show --find-copies-harder' gives me
>> (tools_def.tempate omitted):
>
> Unfortunately git found a copy that is not appropriate for comparison. It
> found the X86/X64 linker script that, while similar, is different than what
> we were already doing for AArch64. (I'm not saying the X86 approach doesn't
> work but my goal here was to minimize the impact to what was already being
> done for AArch64.)
>
OK. so does that mean we are using a builtin linker script for
AArch64? That sounds fragile to me ...
Could you please look at the X64 approach, and compare it to yours?
Personally, I'd prefer to stay as close as possible to what is being
done on Intel, for obvious reasons ...
> On AArch64 the .text section was being placed with this linker switch:
>
> -Ttext=0x0
>
> But this was not sufficient to pack the .data section in a manner that is
> consistent with the PE-COFF conversion that happens later in the build. So
> when I converted this to a linker control file, I maintained the zero
> starting address with:
>
> . = 0;
>
OK, that parts seems obvious. So how is the packing of the .data
section being affected by your version of the linker script?
Perhaps you could share some numbers or other details to get a feel
for what exactly goes on here.
>> So are you saying that the resulting PE/COFF is identical (for all
>> intents and purposes), and only the ELF intermediate file deviates?
>
> Yes, from my testing the PE/COFF looks the same but the ELF is updated to
> move .data such that its offset relative to .text is consistent with PE/COFF.
> This fixes debugger correlation for stuff in the .data section like global
> variables.
>
>> How does this affect
>> ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf,
>> which outputs lines like
>
> >From my testing it has no effect since this output is only outputting the
> >PE-COFF image address offset by the size of the PE-COFF headers (0x260 in
> >this case):
>
> (UINTN)(ImageContext->ImageAddress + ImageContext->SizeOfHeaders))
>
> The reason the SizeOfHeaders is added is because the debugger is unaware of
> the PE-COFF conversion and added executable headers.
>
OK, that makes sense.
> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, June 16, 2015 5:56 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] [PATCH] BaseTools for AArch64 GCC: Ensure that the
> correlation .text and .data is consistent between ELF and PE-COFF so the
> debugger sees global variables correctly
>
> On 4 June 2015 at 21:48, Cohen, Eugene <eug...@hp.com> wrote:
>> Oops, left off the contribution agreement line, trying again
>>
>> Dear ArmPkg maintainers (and later BaseTools maintainer),
>>
>> This is a fix for debugger correlation of global variables for AArch64 built
>> on GCC.
>>
>> Before this change looking at global variables with a debugger showed bogus
>> memory locations. This is because the offset of the .data section in the ELF
>> file did not reflect where it was placed in the PE-COFF (.efi) output.
>>
>> This change passes a linker control script so that the data section is
>> packed next to .text so the ELF accurately reflects the relationship between
>> the sections when converted to PE-COFF by GenFw.
>>
>> I have tested this with the Lauterbach debugger. I don't know how well it
>> will work with other debuggers and debug scripts.
>>
>> If you would rather view the change as a github pull request:
>> https://github.com/tianocore/edk2/pull/12
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Eugene Cohen <eug...@hp.com>
>>
>
> Could you please send patches inline? Attachments are a pain to review.
>
> Also, since the patch introduces a completely new linker script, it is
> hard to review how yours deviates from the default.
> Git is actually quite helpful since it can figure out if your newly
> introduced file resembles an existing file, and only shows the diff
> with respect to the original.
>
> Applying your patch and doing 'git show --find-copies-harder' gives me
> (tools_def.tempate omitted):
>
> """
> diff --git a/BaseTools/Scripts/gcc4.4-ld-script
> b/BaseTools/Scripts/gcc-arm-ld-script
> similarity index 59%
> copy from BaseTools/Scripts/gcc4.4-ld-script
> copy to BaseTools/Scripts/gcc-arm-ld-script
> index 68b2767590ac..e1589a4d03bf 100644
> --- a/BaseTools/Scripts/gcc4.4-ld-script
> +++ b/BaseTools/Scripts/gcc-arm-ld-script
> @@ -1,8 +1,10 @@
> -/* OUTPUT_FORMAT(efi-bsdrv-x86_64) */
> SECTIONS
> {
> - /* . = 0 + SIZEOF_HEADERS; */
> - . = 0x280;
> + /* Start at 0 so we can meet more aggressive alignment requires
> after the PE-COFF conversion
> + like those for ARM exception vectors. This requires debugger
> scripts to offset past
> + the PE-COFF header (typically 0x260). When the PE-COFF
> conversion occurs we will
> + get proper alignment since the ELF section alignment is applied
> in the conversion process. */
> + . = 0;
> .text ALIGN(0x20) :
> {
> *(.text .stub .text.* .gnu.linkonce.t.*)
> """
>
> So are you saying that the resulting PE/COFF is identical (for all
> intents and purposes), and only the ELF intermediate file deviates?
> How does this affect
> ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf,
> which outputs lines like
>
> add-symbol-file
> /home/ard/build/uefi-next/Build/ArmVirtQemu-AARCH64/DEBUG_GCC48/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
> 0x5F2C7260
>
> where the .dll is and ELF file, and the line seems to incorporate the
> header offset that you are removing.
>
> Regards,
> Ard.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
> ------------------------------------------------------------------------------
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
GNU ld (GNU Binutils) Linaro 2014.11-3-git 2.24.0.20141017
Supported emulations:
aarch64elf
aarch64elf32
aarch64elf32b
aarch64elfb
armelf
armelfb
using internal linker script:
==================================================
/* Script for -z combreloc: combine and sort reloc sections */
OUTPUT_FORMAT("elf64-littleaarch64", "elf64-bigaarch64",
"elf64-littleaarch64")
OUTPUT_ARCH(aarch64)
ENTRY(_start)
SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib");
SECTIONS
{
/* Read-only sections, merged into text segment: */
PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x00400000)); . =
SEGMENT_START("text-segment", 0x00400000);
.interp : { *(.interp) }
.note.gnu.build-id : { *(.note.gnu.build-id) }
.hash : { *(.hash) }
.gnu.hash : { *(.gnu.hash) }
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
.gnu.version : { *(.gnu.version) }
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
.rela.dyn :
{
*(.rela.init)
*(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
*(.rela.fini)
*(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)
*(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
*(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
*(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
*(.rela.ctors)
*(.rela.dtors)
*(.rela.got)
*(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
*(.rela.ifunc)
}
.rela.plt :
{
*(.rela.plt)
PROVIDE_HIDDEN (__rela_iplt_start = .);
*(.rela.iplt)
PROVIDE_HIDDEN (__rela_iplt_end = .);
}
.init :
{
KEEP (*(SORT_NONE(.init)))
} =0
.plt : { *(.plt) *(.iplt) }
.text :
{
*(.text.unlikely .text.*_unlikely .text.unlikely.*)
*(.text.exit .text.exit.*)
*(.text.startup .text.startup.*)
*(.text.hot .text.hot.*)
*(.text .stub .text.* .gnu.linkonce.t.*)
/* .gnu.warning sections are handled specially by elf32.em. */
*(.gnu.warning)
} =0
.fini :
{
KEEP (*(SORT_NONE(.fini)))
} =0
PROVIDE (__etext = .);
PROVIDE (_etext = .);
PROVIDE (etext = .);
.rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
.rodata1 : { *(.rodata1) }
.eh_frame_hdr : { *(.eh_frame_hdr) }
.eh_frame : ONLY_IF_RO { KEEP (*(.eh_frame)) }
.gcc_except_table : ONLY_IF_RO { *(.gcc_except_table
.gcc_except_table.*) }
/* These sections are generated by the Sun/Oracle C++ compiler. */
.exception_ranges : ONLY_IF_RO { *(.exception_ranges
.exception_ranges*) }
/* Adjust the address for the data segment. We want to adjust up to
the same address within the page on the next page up. */
. = ALIGN(CONSTANT (MAXPAGESIZE)) + (. & (CONSTANT (MAXPAGESIZE) - 1));
/* Exception handling */
.eh_frame : ONLY_IF_RW { KEEP (*(.eh_frame)) }
.gcc_except_table : ONLY_IF_RW { *(.gcc_except_table .gcc_except_table.*) }
.exception_ranges : ONLY_IF_RW { *(.exception_ranges .exception_ranges*) }
/* Thread Local Storage sections */
.tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
.tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
.preinit_array :
{
PROVIDE_HIDDEN (__preinit_array_start = .);
KEEP (*(.preinit_array))
PROVIDE_HIDDEN (__preinit_array_end = .);
}
.init_array :
{
PROVIDE_HIDDEN (__init_array_start = .);
KEEP (*(SORT(.init_array.*)))
KEEP (*(.init_array ))
PROVIDE_HIDDEN (__init_array_end = .);
}
.fini_array :
{
PROVIDE_HIDDEN (__fini_array_start = .);
KEEP (*(SORT(.fini_array.*)))
KEEP (*(.fini_array ))
PROVIDE_HIDDEN (__fini_array_end = .);
}
.ctors :
{
/* gcc uses crtbegin.o to find the start of
the constructors, so we make sure it is
first. Because this is a wildcard, it
doesn't matter if the user does not
actually link against crtbegin.o; the
linker won't look for a file to match a
wildcard. The wildcard also means that it
doesn't matter which directory crtbegin.o
is in. */
KEEP (*crtbegin.o(.ctors))
KEEP (*crtbegin?.o(.ctors))
/* We don't want to include the .ctor section from
the crtend.o file until after the sorted ctors.
The .ctor section from the crtend file contains the
end of ctors marker and it must be last */
KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
KEEP (*(SORT(.ctors.*)))
KEEP (*(.ctors))
}
.dtors :
{
KEEP (*crtbegin.o(.dtors))
KEEP (*crtbegin?.o(.dtors))
KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
KEEP (*(SORT(.dtors.*)))
KEEP (*(.dtors))
}
.jcr : { KEEP (*(.jcr)) }
.data.rel.ro : { *(.data.rel.ro.local* .gnu.linkonce.d.rel.ro.local.*)
*(.data.rel.ro .data.rel.ro.* .gnu.linkonce.d.rel.ro.*) }
.dynamic : { *(.dynamic) }
.got : { *(.got) *(.igot) }
.got.plt : { *(.got.plt) *(.igot.plt) }
.data :
{
__data_start = . ;
*(.data .data.* .gnu.linkonce.d.*)
SORT(CONSTRUCTORS)
}
.data1 : { *(.data1) }
_edata = .; PROVIDE (edata = .);
. = .;
__bss_start = .;
__bss_start__ = .;
.bss :
{
*(.dynbss)
*(.bss .bss.* .gnu.linkonce.b.*)
*(COMMON)
/* Align here to ensure that the .bss section occupies space up to
_end. Align after .bss to ensure correct alignment even if the
.bss section disappears because there are no input sections.
FIXME: Why do we need it? When there is no .bss section, we don't
pad the .data section. */
. = ALIGN(. != 0 ? 64 / 8 : 1);
}
_bss_end__ = . ; __bss_end__ = . ;
. = ALIGN(64 / 8);
. = SEGMENT_START("ldata-segment", .);
. = ALIGN(64 / 8);
__end__ = . ;
_end = .; PROVIDE (end = .);
/* Stabs debugging sections. */
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
/* DWARF debug sections.
Symbols in the DWARF debugging sections are relative to the beginning
of the section so we begin them at 0. */
/* DWARF 1 */
.debug 0 : { *(.debug) }
.line 0 : { *(.line) }
/* GNU DWARF 1 extensions */
.debug_srcinfo 0 : { *(.debug_srcinfo) }
.debug_sfnames 0 : { *(.debug_sfnames) }
/* DWARF 1.1 and DWARF 2 */
.debug_aranges 0 : { *(.debug_aranges) }
.debug_pubnames 0 : { *(.debug_pubnames) }
/* DWARF 2 */
.debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_line 0 : { *(.debug_line .debug_line.* .debug_line_end ) }
.debug_frame 0 : { *(.debug_frame) }
.debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) }
.debug_macinfo 0 : { *(.debug_macinfo) }
/* SGI/MIPS DWARF 2 extensions */
.debug_weaknames 0 : { *(.debug_weaknames) }
.debug_funcnames 0 : { *(.debug_funcnames) }
.debug_typenames 0 : { *(.debug_typenames) }
.debug_varnames 0 : { *(.debug_varnames) }
/* DWARF 3 */
.debug_pubtypes 0 : { *(.debug_pubtypes) }
.debug_ranges 0 : { *(.debug_ranges) }
/* DWARF Extension. */
.debug_macro 0 : { *(.debug_macro) }
.stack 0x80000 :
{
_stack = .;
*(.stack)
}
.ARM.attributes 0 : { KEEP (*(.ARM.attributes)) KEEP (*(.gnu.attributes)) }
.note.gnu.arm.ident 0 : { KEEP (*(.note.gnu.arm.ident)) }
/DISCARD/ : { *(.note.GNU-stack) *(.gnu_debuglink) *(.gnu.lto_*) }
}
==================================================
------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
