Thanks Chris.
Then I think it would be worth exploring this option.
The advantage I see is, this would make the platform interfaces more obvious, as they would all be gathered in a single place / structure.
However, this might require more engineering work, as for any framework that tries to solve a problem in a generic manner, and I would imagine there will platform-specific exceptions we will have to cater for.
In comparison, the initial solution I proposed sounds easier to implement to me. I am not saying this should rule out the pointer-based solution, just sharing my early thoughts on this.
What I'll do for the time being, I will mention both approaches in the coding guidelines for now. When we start the weak function removal effort in the code base, we can prototype both approaches and revisit these recommendations if one approach stands out.
Best regards, Sandrine
On 2/10/23 14:04, Chris Kay wrote:
I just have a doubt about the performance impact. Would there be any? Or
would the "constness" of these function pointers allow the compiler to optimize and remove any indirection we'd get with mutable function pointers?
Both GCC and Clang can// inline indirect function calls so long as they know that the function pointer is immutable for the lifetime of the program (i.e. const static). [https://gcc.godbolt.org/z/z78M57bq9 https://gcc.godbolt.org/z/z78M57bq9]
Without IPO/LTO, however, the compiler cannot know the destination of the function pointer across compilation unit boundaries. [https://gcc.godbolt.org/z/WWKP6ncx6 https://gcc.godbolt.org/z/WWKP6ncx6]
So with IPO/LTO I would expect to see little to no performance impact, but without it might be a bit more substantial. There aren’t many reasons not to use LTO outside of debugging, so this might be an acceptable performance cost. Size cost might be more problematic for debug images, but it’s difficult to estimate that.
Chris
*From: *Sandrine Bailleux via TF-A tf-a@lists.trustedfirmware.org *Date: *Friday, 10 February 2023 at 12:16 *To: *Varun Wadekar vwadekar@nvidia.com, tf-a tf-a@lists.trustedfirmware.org *Subject: *[TF-A] Re: Coding guidelines update: Discouraging usage of weak functions
Hi Varun,
On 2/9/23 16:20, Varun Wadekar wrote:
Hi,
Although we've not completely thought through all the details, we suspect we will have to isolate each strong implementation under plat/common/ in a separate file such that platforms can pick and choose just the files (and thus, just the functions) they need.
[VW] It would be interesting to see if a function pointer based solution, similar to psci_ops, would be useful.
I see that Raghu raised the same idea in Gerrit, quoting his comment for reference:
Another alternative to providing interfaces is using const function pointers. People may barf at function pointers as a security issue, but conscious use of const function pointers that defines platform interfaces, that must be filled, is another way to get similar effect to weak functions without breaking security or
potential for causing bugs.
I agree that *const* function pointers sound safe from a security point of view.
I just have a doubt about the performance impact. Would there be any? Or would the "constness" of these function pointers allow the compiler to optimize and remove any indirection we'd get with mutable function pointers?
Best regards, Sandrine -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org