Re: Query about variable initialization

[Andrew Fish <afish@apple.com>]

> On Jun 20, 2018, at 12:01 PM, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> 
> On 20 June 2018 at 20:57, Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>> wrote:
>> On 06/20/18 20:03, Ard Biesheuvel wrote:
>>> On 20 June 2018 at 19:48, Evan Lloyd <Evan.Lloyd@arm.com> wrote:
>>>> Hi Ard, Leif.
>>>> I've noticed a number of comments like Ard's recent "We don't permit initialized automatic variables.",
>>>> and similar changes have been made to Sami's AcpiView.  Note: I'm not objecting to doing it the way maintainers prefer, which is why this is not a response.
>>>> 
>>>> My understanding was that the CCS was changed some time back to remove the restriction on initializing variables (and I further think I remember Leif being a prime mover in that).
>>> 
>>> I don't remember, to be honest. But I think it is a stupid rule, and
>>> so if we haven't already, I hope we can get rid of it.
>>> 
>>> IIRC, this limitation had something to do with a particularly nice
>>> exhibit in the Tianocore toolchain museum that generated bigger
>>> binaries for initialized automatic variables (as compared to
>>> assignments performed separately). But let's not get into the
>>> toolchain situation, shall we?
>> 
>> One special case of initialization is when the variable in question has
>> structure type. For such initialization the compiler may generate calls
>> to internal helper functions (memset and friends), and then the module
>> fails to link. I've seen this myself earlier, although I can't tell
>> whether on gcc-4.4 or gcc-4.8.
>> 
> 
> That is a very good point. Note that this does not affect ARM, given
> that we already have to provide the AEABI intrinsics (and memset and
> memcpy for GCC), but I can see how other architectures may be bitten
> by this.
> 
> I suppose the compiler is free to apply the same optimization to a
> block of automatic POD type variables, although I'd be surprised if
> that ever occurs in practice.

What I find is it breaks NOOPT builds, -O0 for clang specifically. Especially for projects that don't have a global NOOPT build due to FLASH Size. 

That common place I hit this it trying to turn off optimization to walk some code in the debugger to understand how it works and now it does not link. 

Usually I'm doing something like this in the INF, or the equivalent in the DSC, and boom. 

[BuildOptions]
  XCODE:*_*_*_CC_FLAGS = -O0 -fno-lto

Thanks,

Andrew Fish


> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>