Thank you very much for answering my question :-) > B is correct. We don't care about function pointers because we know if a > static function has its address takes in the same compilation unit in > which it appears. If it has not had its address taken, we don't have > to care about the system ABI. If it has, then we need to use the system > ABI. > If the address of the static function been taken and then we need to use the > system ABI. Does such action has been documented somewhere inside GCC or as an undocumented convention? Or further, even as an undocumented convention inside all the many mainstream C compilers (GCC, clang ...)? Furthermore, could I make the following conclusion under GCC and Linux? Conclusion: For the "calling" of the C static functions, it has only two possibilities -- either it's been inlined by the compiler optimization (i.e. not actually been called by the `call` instruction but been optimized for the reason of speed), Or it would be actually called (with the `call` instruction) under the "Function Calling Sequence" constraints which have been described in the Sys V ABI specs (same as the calling of those extern C functions). Thanks a lot. On Sun, Dec 30, 2018 at 5:29 AM Andrew Haley <aph@xxxxxxxxxx> wrote: > On 12/29/18 12:53 PM, Remus Clearwater wrote: > > B. The calling of those un-inlined static C functions does not have to > > comply with the function calling sequence defined in the ABI spec. And > > because the calling of the function pointers which are pointing to the > > static C functions has to work correctly as the C standard described, so > it > > is the compiler's free will to decide any "calling sequence" that as long > > as could satisfy both the Sys V ABI and the C standard. > > B is correct. We don't care about function pointers because we know if a > static function has its address takes in the same compilation unit in > which it appears. If it has not had its address taken, we don't have > to care about the system ABI. If it has, then we need to use the system > ABI. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. <https://www.redhat.com> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >
