Conference smurf::unix_objsym

71.0. "$$ellipsis representation" by GEMGRP::MONTELEONE () Tue May 20 1997 19:05

    
    
    I am working on adding support in GEM for "an unspecified number of
    arguments to a routine", i.e. "...".
    
    Here is an example C++ program:
    
    int foo(...);
    
    int foo(int fooparam,int barparam,...) {
    
    return 3;
    
    }
    
    int main () { return foo(1,2,3); }
    
    
    Currently, there is no support for such a construct in GEM based
    compilers (Well actually there is a bit. In the context of a 
    C++ member function, something is emitted for this case. However,
    the end user does not see what would be the "intuitive" representation
    of the information when debugging, so I classify the current state of
    affairs as unsupported...)
    
    This is what the symbol table looks like after being compiled by
    the V5.1 ucode based compiler:
    
    Binary of auxes:
      0. 0x00000000   0x00000018   0x00000009   0x00000018   0x00000018
      5. 0x0000000e   0x00000018
    
    
    Local Symbols:
    from file ellip.cxx   Printf aux if present
      0. ( 0)(   0) ellip.cxx  File       Text       symref 15
      1. ( 1)(   0) foo(int, int, ...) Proc       Text       [ 2] endref 9,
    int
      2. ( 2)(   0) fooparam   Param      Abs        [ 4] int
      3. ( 2)( 0x8) barparam   Param      Abs        [ 4] int
      4. ( 2)( 0xc) $$ellipsis Param      Abs        indexNil
      5. ( 2)(0x10)            Block      Text       symref 8
      6. ( 3)( 0x1) <RESULT>   Local      Register   indexNil
      7. ( 2)(0x20)            End        Text       symref 5
      8. ( 1)(0x2c) foo(int, int, ...) End        Text       symref 1
      9. ( 1)(0x30) main       Proc       Text       [ 5] endref 14, int
     10. ( 2)(0x18)            Block      Text       symref 13
     11. ( 3)( 0x9) <RESULT>   Local      Register   indexNil
     12. ( 2)(0x48)            End        Text       symref 10
     13. ( 1)(0x60) main       End        Text       symref 9
     14. ( 0)(   0) ellip.cxx  End        Text       symref 0
    
    Here is ladebug operating on it:
    
    (ladebug) whatis foo
    int foo(int, int, ...)
    
    
    which looks good to me (unfortunately ladebug asserts when issuing
    a where command after stopping in the routine - I logged the bug
    in the ladebug notes conference). 
    
    
    The only part of the 
    
          4. ( 2)( 0xc) $$ellipsis Param      Abs       indexNil
    
    entry which looks suspect to me is the 0xc value in the value field
    and the storage class.
    
    I believe that the value field, interpreted as an offset, has no
    meaning in this context and thus should always be zero. Ditto for the
    storage class scAbs - we should make it scInfo, marking it as
    information for the debugger only. I am open to enlightenment if 
    someone has a deeper understanding of this entry and appreciates the
    offset and storage class etc.
    
    For now, then, I propose that we stick generally with the current "defacto"
    representation for "..." parameters and define them as such:
    
        value - always 0
        name  - $$ellipsis
        ST    - StParam
        SC    - ScInfo
        aux   - indexNil
    
    $$ellipsis parameter local entries must go in the parameter section
    of a routine, i.e. following the "Proc Text" entry and preceding
    the routines associated "Block Text" entry.
    
    I need to work out an interface between the front end and GEM to
    convey this information to GEM so I can emit it, but that is my
    problem...
    
    Bob

According to the Object Spec Draft 3 Page 176

      stParam, scInfo 

is a "C++ member function parameter".  In your
description you seemed to imply that this st/sc
combo is used more commonly than the spec indicates.

Can anyone shed any light on this?

    
    
    The stParam, scInfo combination is currently only used to describe
    a C++ member function parameter. I believe that the proposal .0 
    describes a logical extension of its use.
    
    Note that C++ member function local entries always exist in a well
    defined context (embedded in the begin-end block of a class definition)
    so there would not be a problem with ambiguity (in case that was the
    concern...)
    
    
    Bob
    

It seems that stParam/scInfo should not be "defined" to mean
parameters of C++ member functions.  As Bob points out, .0 seems to be
a logical extension of its usage.  There are potentially others.  E.g.,
 -- Descriptions of F90 interface blocks (probably not in the symbol
    table today, but if they were they might look like C++ member
    functions).
 -- F90 module procedures descriptions (rather than definitions).
    This is very similar to C++ member functions; an F90 module might
    emit a description just as a C++ class does, whereas the actual
    F90 module procedures are defined/described separately, just as
    the C++ method definitions are.
I think stParam/scInfo should be extended to mean "information about a
parameter, usually name and type, within the context of an
information-based procedure (stProc/scInfo).  Actual details of the
parameter (non-scInfo) are in the context of the actual procedure
(non-scInfo)."

Regarding the 'value' field for $$ellipsis: I think the non-zero value
is correct.  Recall on Alpha/UNIX that the code will more registers as
necessary into the parameters portion of the frame and va_arg knows
how to pull apart the pointer.  Therefore, the value portion of
$$ellipsis should describe where in the parameter portion the va_list
actually starts, and I think the 0xc value in the example in .0 is
trying to do this.  Whether 0xc is the correct value (should it be
0x10?) is a different question.  I think scAbs is also correct, since
it is the absolute position within the parameter block, just like the
other parameters.

[Posted by WWW Notes gateway]