Re: request for feature

From: Tom Hughes (thh_at_cyberscience.com)
Date: Tue Apr 09 2002 - 09:38:24 BST

  • Next message: Rod Armstrong: "Re: UPS tracing"
    In message <200204031940.g33JeGT27315_at_nanga>
            Rod Armstrong <rod_at_san-jose.tt.slb.com> wrote:
    
    > I understand the problem now. Without defining the type in file x.c,
    > ups cannot expand it. This is because type information is scoped to
    > compilation units. Why not include the type definitions in files
    > where you want to examine the structure? The ups type scoping
    > is just the same as the compiler. For instance, if x.c were written as:
    
    In principle the ups type scoping is the same, yes. In practice it is
    more complicated than that due to the mad things that the linker does
    to the stabs.
    
    There is a common C idiom whereby an incomplete type is declared in a
    header file and it is then made complete by a definition in the file
    that implements the data type. This means that routines in other files
    are forced to go through the public interface to manipulate the
    contents of the struct instead of mucking about with the internals
    directly. It provides a basic form of abstract types in C.
    
    Unfortunately when this is done the stabs get rather complicated and
    ups fails to decode them properly. There are additional complications
    related to stab optimisations done by the linker for duplicate
    instances of header files in the same target.
    
    Even debugging of ups sometimes falls foul of this - there are a
    number of structs which can't be expanded properly.
    
    I do have a patch which attempts to fix all this, but it still doesn't
    really work very well and I need to try and come up with a better
    solution but it is all rather involved.
    
    Tom
    
    -- 
    Tom Hughes (thh_at_cyberscience.com)
    Software Engineer, Cyberscience Corporation
    http://www.cyberscience.com/
    


    This archive was generated by hypermail 2.1.4 : Thu May 23 2002 - 15:54:13 BST