Hi Xi and Andrew :-)
> > > 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 ...)?
>
> The compiler must obey the C standard and this is the reasonable way to
> make it so.
Yes, it is indeed a very reasonable and elegant way but maybe still not the
only choice a C compiler could make. Say there is certain C compiler tool
chain implementation named XCC:
1. XCC obey the Sys V ABI when calling extern C functions (same as GCC
does).
2. XCC always use a self defined calling convention named
XCC_CALL_For_Static_Functions to call the static C functions.
3. The XCC's XCC_CALL_For_Static_Functions is completely different from the
calling sequence defined in the Sys V ABI.
4. Here is how XCC generated executable binaries (say XBIN for example)
calling static C functions:
4.1. XBIN always maintain a set of all the extern functions'
address, and the name of this set is "XSET".
4.2. When doing function call via any variable function pointers,
it would check the XSET, if the function pointer pointing to an extern
function it would choose to use the Sys V ABI Calling Sequence, otherwise
the XCC_CALL_For_Static_Functions would be used.
4.3. For the calling of constant function pointers, XCC will try
its best to optimize the process described in 4.2 above.
5. XCC obey the Sys V ABI and C specs.
I think such XCC above is self-consistent and could be implemented (as far
as the depth I know about the ABI and C specs now). I would be very glad if
you could point out the inconsistency of XCC.
Thanks a lot.
