From: "Ard Biesheuvel" <ard.biesheuvel@arm.com>
To: Laszlo Ersek <lersek@redhat.com>,
"Liming Gao (Byosoft address)" <gaoliming@byosoft.com.cn>
Cc: devel@edk2.groups.io, mojha@codeaurora.org, discuss@edk2.groups.io
Subject: Re: [edk2-devel] : Query regarding IsTextShdr inside Basetools
Date: Thu, 12 Nov 2020 09:23:43 +0100 [thread overview]
Message-ID: <086e1e01-7ab5-d877-480f-62f588b84300@arm.com> (raw)
In-Reply-To: <7b920231-f763-06d6-c69c-a97123c7a4be@redhat.com>
On 11/11/20 11:41 PM, Laszlo Ersek wrote:
> On 11/11/20 23:40, Laszlo Ersek wrote:
>> Ard, Liming,
>>
>> can you please take a look?
>>
>> Thanks!
>> Laszlo
>
> Darn, I used Liming's old email address. Correcting it now. Sorry!
>
> Laszlo
>
>>
>> On 11/10/20 14:07, Mukesh Ojha wrote:
>>> Hi All,
>>>
>>> I have a doubt about the check we have put inside IsTextShdr() .
>>>
>>> STATIC
>>> BOOLEAN
>>> IsTextShdr (
>>> Elf_Shdr *Shdr
>>> )
>>> {
>>> return (BOOLEAN) ((Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) ==
>>> SHF_ALLOC);
>>> }
>>>
>>>
>>> We are observing one issue where while generate EFI using GenFW in EDK2
>>> because test/data section offset is different than calculated
>>> mCoffSectionsOffset when scanning sections.
>>> I run GenFW with a failure dll in my local after adding some logs into
>>> GenFW. and found that “mCoffSectionsOffset” for data section seems not
>>> to have expected value due to
>>> “.note.gnu.property” size. Because compiled dll has “.note.gnu.property”
>>> section with alloc flag and GenFW thinks that it’s a text section if
>>> alloc flag is set.
>>> So its size is added to the mCoffSectionsOffset.
>>>
>>> Could you please give us an advice whether we can fix IsTextShdr()
>>> function like below ?
>>>
>>>
>>> --- a/BaseTools/Source/C/GenFw/Elf64Convert.c
>>> +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
>>> @@ -229,7 +229,7 @@ IsTextShdr (
>>> Elf_Shdr *Shdr
>>> )
>>> {
>>> - return (BOOLEAN) ((Shdr->sh_flags & (SHF_WRITE | SHF_ALLOC)) ==
>>> SHF_ALLOC);
>>> + return (BOOLEAN) ((Shdr->sh_flags & (SHF_EXECINSTR | SHF_WRITE |
>>> SHF_ALLOC)) == (SHF_ALLOC | SHF_EXECINSTR));^
>>>
Was this ELF executable built using the GccBase.lds linker script? If
so, we should fix it to disregard .note sections.
If you are not using GccBase.lds, I'm afraid you are simply in
unsupported territory - there are too many assumptions in GenFw that are
not guaranteed to hold for arbitrary ELF executables.
I don't think changing IsTextShdr() is the right approach here.
next prev parent reply other threads:[~2020-11-12 8:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-10 13:07 [edk2-devel] : Query regarding IsTextShdr inside Basetools mojha
2020-11-11 22:40 ` Laszlo Ersek
2020-11-11 22:41 ` Laszlo Ersek
2020-11-12 8:23 ` Ard Biesheuvel [this message]
[not found] <164632B1BC861BDB.31324@groups.io>
2020-11-11 7:07 ` Mukesh Ojha
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=086e1e01-7ab5-d877-480f-62f588b84300@arm.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