145
|
1 @c Copyright (C) 1988-2020 Free Software Foundation, Inc.
|
0
|
2 @c This is part of the GCC manual.
|
|
3 @c For copying conditions, see the file gcc.texi.
|
|
4
|
|
5 @node Interface
|
|
6 @chapter Interfacing to GCC Output
|
|
7 @cindex interfacing to GCC output
|
|
8 @cindex run-time conventions
|
|
9 @cindex function call conventions
|
|
10 @cindex conventions, run-time
|
|
11
|
|
12 GCC is normally configured to use the same function calling convention
|
|
13 normally in use on the target system. This is done with the
|
|
14 machine-description macros described (@pxref{Target Macros}).
|
|
15
|
|
16 @cindex unions, returning
|
|
17 @cindex structures, returning
|
|
18 @cindex returning structures and unions
|
|
19 However, returning of structure and union values is done differently on
|
|
20 some target machines. As a result, functions compiled with PCC
|
|
21 returning such types cannot be called from code compiled with GCC,
|
|
22 and vice versa. This does not cause trouble often because few Unix
|
|
23 library routines return structures or unions.
|
|
24
|
|
25 GCC code returns structures and unions that are 1, 2, 4 or 8 bytes
|
|
26 long in the same registers used for @code{int} or @code{double} return
|
|
27 values. (GCC typically allocates variables of such types in
|
|
28 registers also.) Structures and unions of other sizes are returned by
|
|
29 storing them into an address passed by the caller (usually in a
|
|
30 register). The target hook @code{TARGET_STRUCT_VALUE_RTX}
|
|
31 tells GCC where to pass this address.
|
|
32
|
|
33 By contrast, PCC on most target machines returns structures and unions
|
|
34 of any size by copying the data into an area of static storage, and then
|
|
35 returning the address of that storage as if it were a pointer value.
|
|
36 The caller must copy the data from that memory area to the place where
|
|
37 the value is wanted. This is slower than the method used by GCC, and
|
|
38 fails to be reentrant.
|
|
39
|
|
40 On some target machines, such as RISC machines and the 80386, the
|
|
41 standard system convention is to pass to the subroutine the address of
|
|
42 where to return the value. On these machines, GCC has been
|
|
43 configured to be compatible with the standard compiler, when this method
|
|
44 is used. It may not be compatible for structures of 1, 2, 4 or 8 bytes.
|
|
45
|
|
46 @cindex argument passing
|
|
47 @cindex passing arguments
|
|
48 GCC uses the system's standard convention for passing arguments. On
|
|
49 some machines, the first few arguments are passed in registers; in
|
|
50 others, all are passed on the stack. It would be possible to use
|
|
51 registers for argument passing on any machine, and this would probably
|
|
52 result in a significant speedup. But the result would be complete
|
|
53 incompatibility with code that follows the standard convention. So this
|
|
54 change is practical only if you are switching to GCC as the sole C
|
|
55 compiler for the system. We may implement register argument passing on
|
|
56 certain machines once we have a complete GNU system so that we can
|
|
57 compile the libraries with GCC@.
|
|
58
|
|
59 On some machines (particularly the SPARC), certain types of arguments
|
|
60 are passed ``by invisible reference''. This means that the value is
|
|
61 stored in memory, and the address of the memory location is passed to
|
|
62 the subroutine.
|
|
63
|
|
64 @cindex @code{longjmp} and automatic variables
|
|
65 If you use @code{longjmp}, beware of automatic variables. ISO C says that
|
|
66 automatic variables that are not declared @code{volatile} have undefined
|
|
67 values after a @code{longjmp}. And this is all GCC promises to do,
|
|
68 because it is very difficult to restore register variables correctly, and
|
|
69 one of GCC's features is that it can put variables in registers without
|
|
70 your asking it to.
|