Hi Raef,
It's look like GCC create a separate instance for each fih_int variable and keep it even out of scope of visibility. So, each FIH_CALL produces own set of variables in function stack even for a release build.
That is interesting - I was under the impression that having the structure marked as volatile was semantically the same as having all of its member volatile. Do you notice a considerable stack usage change with this fix?
For example there is difference about 500 bytes for tfm_hal_set_up_static_boundaries in our platform.
Best regards,
Roman.
-----Original Message-----
From: Raef Coles Raef.Coles@arm.com
Sent: Monday, December 11, 2023 11:09
To: tf-m@lists.trustedfirmware.org; Mazurak Roman (CSS ICW SW FW 3) Roman.Mazurak@infineon.com
Subject: Re: FIH volatile structure and stack usage
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.
Hey Roman
That is interesting - I was under the impression that having the structure marked as volatile was semantically the same as having all of its member volatile. Do you notice a considerable stack usage change with this fix?
I think if you do notice one, we'd be happy to have that change upstream. There's always some performance/size penalty to the FIH code but we should definitely try to minimize it if we can.
Raef
________________________________________
From: Roman.Mazurak--- via TF-M tf-m@lists.trustedfirmware.org
Sent: 08 December 2023 19:58
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] FIH volatile structure and stack usage
Hi all,
I found that using FIH medium/high profile with gcc generates code that uses stack extensively. It happens because fih_int structure is marked as volatile.
Is there any reason why structure itself is marked as volatile? Why it's not enough to make val and msk volatile members of fih_int structure?
Best regards,
Roman.