Which spec has defined the calling sequence of static C functions (like the extern C functions' has been defined in the Sys V ABI specs)?

Which spec has defined the calling sequence of static C functions (like the extern C functions' has been defined in the Sys V ABI specs)?

[Remus Clearwater]

Hi,

I am sure that the standard "Function Calling Sequence" described in Sys V
ABI specs (both i386 and AMD64) applies to the calling of those extern
functions in a C library, but does it applies to the calling of those
static C functions too if we do not take the compiler's "inline"
optimization into account (say such "inline" optimization has been switched
off)?

I think it should have two possibilities -- A and B:

A. The calling of those un-inlined static C functions should also comply
with the function calling sequence details (including registers usage,
stack frame, parameters passing, variable arguments...) which is defined in
the Sys V ABI spec just like the extern C functions do.

I think A should be correct. But I didn't manage to find any detailed
reference in the Sys V ABI specs (i386 & AMD64) or in the C standard.

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.

If B is right, then what is the special "calling sequence" GCC chooses for
calling static C functions? Is GCC just use the same "Function Calling
Sequence" rule which has been described in Sys V ABI specs (same as the
calling of those extern C functions)?

Thank you very much.

PS:

This question has been discussed on the SO yesterday, but I didn't manage
to get an exact answer.

-- 
https://stackoverflow.com/questions/53958062/does-the-standard-function-calling-sequence-described-in-sys-v-abi-specs-both

Thanks a lot.

Re: Which spec has defined the calling sequence of static C functions (like the extern C functions' has been defined in the Sys V ABI specs)?

[Andrew Haley]

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

Re: Which spec has defined the calling sequence of static C functions (like the extern C functions' has been defined in the Sys V ABI specs)?

[Remus Clearwater]

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@redhat.com> 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
>

Re: Which spec has defined the calling sequence of static C functions (like the extern C functions' has been defined in the Sys V ABI specs)?

[Xi Ruoyao]

On 2018-12-30 17:58 +0800, Remus Clearwater wrote:
> > 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.

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

No.  The compiler may use customized calling convention to maximize the
performance unless this function may be called in other translation units.
-- 
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University

Re: Which spec has defined the calling sequence of static C functions (like the extern C functions' has been defined in the Sys V ABI specs)?

[Andrew Haley]

On 12/30/18 10:43 AM, Xi Ruoyao wrote:
> On 2018-12-30 17:58 +0800, Remus Clearwater wrote:
>>    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).
> 
> No.  The compiler may use customized calling convention to maximize the
> performance unless this function may be called in other translation units.

That's exactly right. We can do anything we want inside a translation unit
as long as we provide standard interfaces to everything reachable from
outside the translation unit.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Which spec has defined the calling sequence of static C functions (like the extern C functions' has been defined in the Sys V ABI specs)?

[Remus Clearwater]

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.

Re: Which spec has defined the calling sequence of static C functions (like the extern C functions' has been defined in the Sys V ABI specs)?

[Remus Clearwater]

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

Suddenly appear to me that it would be much tricky if some C library choose
to export an extern C function pointer variable. I didn't notice such
situation a moment ago.

Re: Which spec has defined the calling sequence of static C functions (like the extern C functions' has been defined in the Sys V ABI specs)?

[Remus Clearwater]

>
> > 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).
>
> No.  The compiler may use customized calling convention to maximize the
> performance unless this function may be called in other translation units.
>

Thank you very much, Xi. This information is very useful to me. Because I
have never known the existence of such kind optimization before. It is
brilliant! Do you mind to provide an example about such optimization --
"customized calling convention about the calling of some static functions"
in GCC?

Thanks a lot :-)

Re: Which spec has defined the calling sequence of static C functions (like the extern C functions' has been defined in the Sys V ABI specs)?

[Florian Weimer]

* Andrew Haley:

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

With the caveat that system ABI still has to be followed for global
concerns, such as red zones and unwinding information.  But on many
architectures, it is possible to relax requirements regarding register
spilling, calling convention, and stack alignment.

Thanks,
Florian