Query about variable initialization

Query about variable initialization

[Evan Lloyd]

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).
If that is the case, I suspect the real problem is with ECC.py, which still whinges about it, so probably needs fixing.
Can you confirm that I haven't got a firm grasp on the wrong end of the stick, please?

Regards,
Evan

 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'

Re: Query about variable initialization

[Ard Biesheuvel]

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?

> If that is the case, I suspect the real problem is with ECC.py, which still whinges about it, so probably needs fixing.
> Can you confirm that I haven't got a firm grasp on the wrong end of the stick, please?
>

I could not find the limitation in the current version of the CCS, and
so whether it was there at /some/ point doesn't seem relevant to me.
We could file a bugzilla, and/or propose a patch that removes this
part from ECC.py (although I am not touching the python code if I can
avoid it)

Re: Query about variable initialization

[Laszlo Ersek]

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.

Thanks,
Laszlo

>> If that is the case, I suspect the real problem is with ECC.py, which still whinges about it, so probably needs fixing.
>> Can you confirm that I haven't got a firm grasp on the wrong end of the stick, please?
>>
> 
> I could not find the limitation in the current version of the CCS, and
> so whether it was there at /some/ point doesn't seem relevant to me.
> We could file a bugzilla, and/or propose a patch that removes this
> part from ECC.py (although I am not touching the python code if I can
> avoid it)
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

Re: Query about variable initialization

[Ard Biesheuvel]

On 20 June 2018 at 20:57, Laszlo Ersek <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.

Re: Query about variable initialization

[Andrew Fish]

> 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>