| (The following proposal was posted by Bob Monteleone under a new note
id. I've moved his text here to keep the discussion in one place.)
Currently, the symbol table support for describing pointer to function
types is inadequate. Specifically, there is no way to describe the
parameters of a pointer to function type.
Consider the following source:
typedef struct _foo {
int i;
float j;
} Foo;
void main()
{
int simple(int, int, Foo, int (*)(float, int, Foo));
int fun(float, int, Foo);
Foo aFoo = {1, 2.3};
simple(1, 2, aFoo, fun);
}
int simple(int x, int y, Foo f, int (*z)(float, int, Foo))
{
(*z)(x,y,f);
}
int fun(float a, int b, Foo c)
{
printf("%g, %d, %g, %d\n", a, b, c.i, c.j);
}
Here is the symbol table produced by GEM - note local symbol 15:
FILE 0. unmergable, preexisting, C:
Binary of auxes:
0. 0x000000fc 0xffffffff 0x00000000 0x00000018 0x00000068
5. 0x00000028 0x00000030 0x00001fff 0x00000000 0x0000003c
10. 0x00005fff 0x00000000 0x0000000b 0x00000068 0x00000013
15. 0x00000018 0x00120018 0x0000001a 0x00000018
Local Symbols:
from file f.c Printf aux if present
0. ( 0)( 0) f.c File Text symref 27
1. ( 1)( 0x8) _foo Block Info symref 5
2. ( 2)( 0) i Member Info [ 3] int
3. ( 2)(0x20) j Member Info [ 5] float
4. ( 1)( 0) _foo End Info symref 1
5. ( 1)( 0) Foo Typdef Info [ 6] struct(extended file 0, in
dex 1)
6. ( 1)( 0) main Proc Text [12] endref 11, void
7. ( 2)(0x10) Block Text symref 10
8. ( 3)(0xfffffffffffffff8) aFoo Local Abs [ 9] typedef(exte
nded file 0, index 5)
9. ( 2)(0x44) End Text symref 7
10. ( 1)(0x50) main End Text symref 6
11. ( 1)(0x50) simple Proc Text [14] endref 19, int
12. ( 2)( 0xa) x Param Register [ 3] int
13. ( 2)( 0x9) y Param Register [ 3] int
14. ( 2)(0x20) f Param Abs [ 9] typedef(extended file 0, i
ndex 5)
15. ( 2)(0x18) z Param Abs [16] Pointer to Function
returning int
*******************************************************************************
16. ( 2)(0x28) Block Text symref 18
The current mechanism used to describe functions is to set the tqProc bit.
So, the aux sequence for a pointer to function returning int would be:
0x00120018
There is no way to represent such a function's parameter types.
I propose that we employ the model currently used to represent C++ member
function types to describe pointer to function types with parameters.
Here is an example of a C++ member function description, for reference:
97. ( 2)( 0) ::operator =(const &) Proc Info
[153] endref 101, Reference struct(file 7, index 88)
98. ( 3)( 0) this Param Info
[156] Const Pointer to struct(file 7, index 88)
99. ( 3)( 0) Param Info
[158] Reference Const struct(file 7, index 88)
100. ( 2)( 0) ::operator =(const &) End Info symref 97
The format is as follows:
st sc aux
1. stProc scInfo First aux is a the local entry number of the
the stProc's matching stEnd's local entry number
plus 1. The remaining auxes describe the type
that the function returns, nil if a procedure.
2. ... N. stParam scInfo An aux sequence that describes the type of the
parameter.
N + 1. stEnd scInfo A reference to the local entry number
corresponding to the matching stProc scInfo.
References to such a structure would require a new base type, which would
be modeled after current types which have local symbol table entry components
(e.g. btTypedef, btStruct, btClass, btUnion etc.), which are described as
a bt aux followed by a RNDX aux which references the beginning of the local
symbol table entry component.
So, to describe the function component of a pointer to function type
with parameters, the aux sequence would be btProc (similar to tqProc)
followed by a RNDX pointing to the beginning of the local symbol table
entry component of the procedure.
Referring to the example program, above, I would envision that "z",
which is currently described as:
aux 16: 0x00120018
15. ( 2)(0x18) z Param Abs [16] Pointer to Function
returning int
would be described as such:
aux 16: 0x000100(hex value for btProc) next aux : rndx (file 0, index 20)
15. ( 2)(0x18) z Param Abs [16] Pointer to Function
(float, int, Foo)
returning int
...
20. ( 1)(0) Proc Info [14] endref 25, int
21. ( 2)(0) Param Info [ 3] int
22. ( 2)(0) Param Info [ 3] int
23. ( 2)(0) Param Info [ 9] typedef(extended file 0,
index 5)
24. ( 1)(0) End Text symref 20
An issue to consider is whether tqProc is necessary anymore, since its
functionality is subsumed with the introduction of the btProc type.
tqProc could be still used for describing function types which do not
have parameters, as it offers a more concise description for such a type,
in comparison with the btProc type description.
Bob
|