public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "Song, BinX" <binx.song@intel.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	"Gao, Liming" <liming.gao@intel.com>
Subject: Re: [PATCH] MdeModulePkg: Fix GCC48/GCC49 build error
Date: Mon, 3 Apr 2017 18:34:28 +0200	[thread overview]
Message-ID: <7fe99ab9-78c8-94d5-fa00-94cd342768be@redhat.com> (raw)
In-Reply-To: <CAKv+Gu-YCgcXC1=5YtCQVN=haT90b9CD6CLpFmb=8pLLAoCDLA@mail.gmail.com>

On 04/03/17 18:21, Ard Biesheuvel wrote:
> On 3 April 2017 at 17:16, Laszlo Ersek <lersek@redhat.com> wrote:
>> adding Ard
>>
>> On 04/01/17 10:38, Song, BinX wrote:
>>> - Fix GCC48/GCC49 build error
>>>
>>> Cc: Liming Gao <liming.gao@intel.com>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Bell Song <binx.song@intel.com>
>>> ---
>>>  .../Library/BrotliCustomDecompressLib/BrotliCustomDecompressLib.inf    | 3 +++
>>>  1 file changed, 3 insertions(+)
>>>
>>> diff --git a/MdeModulePkg/Library/BrotliCustomDecompressLib/BrotliCustomDecompressLib.inf b/MdeModulePkg/Library/BrotliCustomDecompressLib/BrotliCustomDecompressLib.inf
>>> index 578f97f..4c9aff5 100644
>>> --- a/MdeModulePkg/Library/BrotliCustomDecompressLib/BrotliCustomDecompressLib.inf
>>> +++ b/MdeModulePkg/Library/BrotliCustomDecompressLib/BrotliCustomDecompressLib.inf
>>> @@ -54,3 +54,6 @@
>>>    DebugLib
>>>    BaseMemoryLib
>>>    ExtractGuidedSectionLib
>>> +
>>> +[BuildOptions]
>>> +  GCC:*_*_*_CC_FLAGS = -fno-builtin
>>>
>>
>> In "BaseTools/Conf/tools_def.template", we currently have:
>>
>> DEFINE GCC_ARM_CC_FLAGS            = DEF(GCC_ALL_CC_FLAGS) [...] -fno-builtin [...]
>> DEFINE GCC_AARCH64_CC_FLAGS        = DEF(GCC_ALL_CC_FLAGS) [...] -fno-builtin [...]
>>
>> DEFINE GCC5_IA32_CC_FLAGS            = DEF(GCC49_IA32_CC_FLAGS) -fno-builtin
>> DEFINE GCC5_X64_CC_FLAGS             = DEF(GCC49_X64_CC_FLAGS) -fno-builtin
>>
>> Now, GCC5_IA32_CC_FLAGS goes back to GCC44_ALL_CC_FLAGS, via:
>> - GCC49_IA32_CC_FLAGS
>> - GCC48_IA32_CC_FLAGS
>> - GCC47_IA32_CC_FLAGS
>> - GCC46_IA32_CC_FLAGS
>> - GCC45_IA32_CC_FLAGS
>> - GCC44_IA32_CC_FLAGS
>> - GCC44_ALL_CC_FLAGS
>>
>> (similarly for GCC5_X64_CC_FLAGS.)
>>
>> So, instead of this patch for BrotliCustomDecompressLib, how about:
>>
>> - moving "-fno-builtin" from
>>     GCC_ARM_CC_FLAGS and
>>     GCC_AARCH64_CC_FLAGS
>>   to
>>     GCC_ALL_CC_FLAGS, and
>>
>> - moving "-fno-builtin" from
>>     GCC5_IA32_CC_FLAGS and
>>     GCC5_X64_CC_FLAGS
>>   to
>>     GCC44_ALL_CC_FLAGS?
>>
>> Do we have any reason for permitting builtins at all?
>>
> 
> Well, one thing I noticed the other day is that GCC does not
> 'recognize' memcpy() and memset() when -fno-builtin is defined, which
> means trivial memcpys and memsets will not be inlined.

But memcpy() and memset(), as written, cannot be called in edk2 anyway

- explicitly, because we don't allow that,

- implicitly (via struct assignment or initialization, for example),
because we forbid that as well -- source code is supposed to use
CopyMem(), CopyGuid(), and the like.

So, yes, memcpy() and memset() would not be inlined with my suggestion,
but edk2 code shouldn't exist in the first place that leads to the
generation of memcpy() and memset() calls.

> I guess that
> argues for not permitting it at all, but it also means adding it
> unconditionally may affect how code is currently generated for some
> platforms.

If said code doesn't conform to the above requirement, then yes, it
could happen.

Thanks!
Laszlo



  reply	other threads:[~2017-04-03 16:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-01  8:38 [PATCH] MdeModulePkg: Fix GCC48/GCC49 build error Song, BinX
2017-04-03 16:16 ` Laszlo Ersek
2017-04-03 16:21   ` Ard Biesheuvel
2017-04-03 16:34     ` Laszlo Ersek [this message]
2017-04-05  4:52       ` Gao, Liming
2017-04-05  8:03         ` Laszlo Ersek

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=7fe99ab9-78c8-94d5-fa00-94cd342768be@redhat.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