Conference smurf::unix_objsym

72.0. "Representation of function types which have parameters" by GEMEVN::MONTELEONE () Wed May 21 1997 18:28

  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