From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: "Gao, Liming" <liming.gao@intel.com>
Cc: "Shi, Steven" <steven.shi@intel.com>,
"Zhu, Yonghong" <yonghong.zhu@intel.com>,
edk2-devel-01 <edk2-devel@lists.01.org>
Subject: Re: [PATCH] BaseTools/GccBase.lds: don't copy RELA section to PE/COFF
Date: Mon, 22 Aug 2016 09:25:54 +0200 [thread overview]
Message-ID: <CAKv+Gu-2mLZsbXqhT9EFZ2uqi603c62=_a2euhj+cOcWhEBWpA@mail.gmail.com> (raw)
In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A1155ED770@shsmsx102.ccr.corp.intel.com>
On 22 August 2016 at 09:22, Gao, Liming <liming.gao@intel.com> wrote:
> Ard:
> Sorry. I miss this patch. GccBase.lds is used by GCC44~GCC5. GCC44~GCC49 doesn't enable LTO, GCC5 enables LTO. That means RELA section is not used with LTO or without LTO. Right?
The allocatable RELA section is only emitted when linking a PIE binary
(i.e., the -pie linker switch, not the -fpie compiler switch). It
contains ELF relocations that the PE/COFF loader does not understand.
CLANG38LTO is the first toolchain to use the -pie linker switch, GCC5
does use PIE objects but does not create a PIE binary at link time.
In some cases, (i.e., when we add support for GOT based relocations),
the contents of this RELA section must be taken into account by GenFw,
but currently, it can only contain relocations that are duplicates of
the relocations we encounter in the non-allocatable RELA sections
(.rela.text, .rela.data etc etc)
So it never makes sense to copy it into the PE/COFF binary, regardless
of whether we inspect its contents or not.
--
Ard.
>
> Thanks
> Liming
>> -----Original Message-----
>> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
>> Sent: Monday, August 22, 2016 3:11 PM
>> To: Shi, Steven <steven.shi@intel.com>; Zhu, Yonghong
>> <yonghong.zhu@intel.com>; Gao, Liming <liming.gao@intel.com>; edk2-
>> devel-01 <edk2-devel@lists.01.org>
>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Subject: Re: [PATCH] BaseTools/GccBase.lds: don't copy RELA section to
>> PE/COFF
>>
>> On 10 August 2016 at 10:55, Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> wrote:
>> > The CLANG38 toolchain creates a PIE binary at link time. This is
>> > necessary since the LTO code generation may otherwise result in
>> > code that cannot execute correctly when loaded above 2 GB.
>> >
>> > PIE executables contain a RELA section consisting of dynamic
>> > relocation entries that are intended for consumption by the loader
>> > at runtime. For this reason, it has the SHF_ALLOC attribute set by
>> > default, and will be identified by GenFw as a section that needs to
>> > be copied into the PE/COFF binary, resulting in waste of space since
>> > the PE/COFF loader does not use this data at all.
>> >
>> > So mark the RELA section as informational: this will prevent the
>> > linker from setting the SHF_ALLOC attribute, causing GenFw to
>> > ignore it.
>> >
>> > DxeCore.efi before:
>> >
>> > Detected 'X64' type PE/COFF image consisting of 3 sections
>> > Section alignment: 0x40
>> > File alignment: 0x40
>> > Section '.text' @ 0x00000240
>> > File offset: 0x240
>> > Virtual size: 0x21000
>> > Raw size: 0x21000
>> > Section '.data' @ 0x00021240
>> > File offset: 0x21240
>> > Virtual size: 0x3640
>> > Raw size: 0x3640
>> > Section '.reloc' @ 0x00024880
>> > File offset: 0x24880
>> > Virtual size: 0x280
>> > Raw size: 0x280
>> >
>> > DxeCore.efi after:
>> >
>> > Detected 'X64' type PE/COFF image consisting of 3 sections
>> > Section alignment: 0x40
>> > File alignment: 0x40
>> > Section '.text' @ 0x00000240
>> > File offset: 0x240
>> > Virtual size: 0x1f440
>> > Raw size: 0x1f440
>> > Section '.data' @ 0x0001f680
>> > File offset: 0x1f680
>> > Virtual size: 0x3640
>> > Raw size: 0x3640
>> > Section '.reloc' @ 0x00022cc0
>> > File offset: 0x22cc0
>> > Virtual size: 0x280
>> > Raw size: 0x280
>> >
>> > Contributed-under: TianoCore Contribution Agreement 1.0
>> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>
>> Steven, Liming: any comments?
>>
>> > ---
>> > BaseTools/Scripts/GccBase.lds | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds
>> > index 281af8a9bd33..900848747144 100644
>> > --- a/BaseTools/Scripts/GccBase.lds
>> > +++ b/BaseTools/Scripts/GccBase.lds
>> > @@ -54,7 +54,7 @@ SECTIONS {
>> > KEEP (*(.eh_frame))
>> > }
>> >
>> > - .rela ALIGN(CONSTANT(COMMONPAGESIZE)) : {
>> > + .rela (INFO) : {
>> > *(.rela .rela.*)
>> > }
>> >
>> > --
>> > 2.7.4
>> >
next prev parent reply other threads:[~2016-08-22 7:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-10 8:55 [PATCH] BaseTools/GccBase.lds: don't copy RELA section to PE/COFF Ard Biesheuvel
2016-08-22 7:10 ` Ard Biesheuvel
2016-08-22 7:22 ` Gao, Liming
2016-08-22 7:25 ` Ard Biesheuvel [this message]
2016-08-22 8:47 ` Gao, Liming
2016-08-22 8:56 ` Shi, Steven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKv+Gu-2mLZsbXqhT9EFZ2uqi603c62=_a2euhj+cOcWhEBWpA@mail.gmail.com' \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox