[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::c_plus_plus

Title:C++
Notice:Read 1.* and use keywords (e.g. SHOW KEY/FULL KIT_CXX_VAX_VMS)
Moderator:DECCXX::AMARTIN
Created:Fri Nov 06 1987
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3604
Total number of notes:18242

3465.0. "Reference issue with Debug??" by KERNEL::PULLEY (Come! while living waters flow) Tue Feb 25 1997 11:51

Hi,

I've a customer having trouble with C++ & Debug.
I've not actually quite managed to figure out exactly how to see the results
he says he is, but below is a description of what he reckons happens.

Thanks for anything anyone can add,
Steve.

The customer's description:-
--------------------------------------------------------------------------------
Here is a simple example demonstrating a reference examine problem in
T7.1C-005 debugger with t5.5-010 CXX and OpenVMS v6.2 Alpha.
If you step into the CLock constructor then examine rSem and
m_rSemaphore you will see the latter is not displayed correctly.
If you add code to print the address of both references
you will see that both have the same address.
This problem does not exists when using T5.4-007Cxx and T7.1C-001 debugger.
The program was compiled with
$ cxx/noopt/debug/include=<> test_debug
--------------------------------------------------------------------------------

The .hxx file, count_semaphore.hxx:-
--------------------------------------------------------------------------------
#ifndef _COUNT_SEMAPHORE_HXX_
#define _COUNT_SEMAPHORE_HXX_

class CCntSemaphore
{
public:

   class CLock
   {
   protected:
      int             m_lSemCount;
      int             m_lFlags;
      CCntSemaphore & m_rSemaphore;

   public:

     
      CLock( CCntSemaphore & rSem ) : m_lSemCount( 0 ), m_lFlags( 0 ),
m_rSemaphore( rSem )
     {
     //----------------------------------------------------------
     //examine rSem, examine m_rSemaphore and they are different!
     //----------------------------------------------------------
     }

     ~CLock()
	{}
    };

protected:

//---------------------
//Start of member data
//---------------------

int      m_lSemId;      //Semaphore ID
int      m_lFlags;      //Semaphore connect/create flags

//---------------------
//End of member data
//---------------------
public:

   CCntSemaphore() : m_lSemId( 0 ), m_lFlags( 0 )
   {
   }
};

#endif // _COUNT_SEMAPHORE_HXX_
--------------------------------------------------------------------------------

The .cxx file:-
--------------------------------------------------------------------------------
#include <count_semaphore.hxx>

main( int argc, char * argv[] )
{
    CCntSemaphore Sem;
    {
       CCntSemaphore::CLock ApplyLock( Sem );

       //-------------------------------
       //Do actions needing to be locked
       //-------------------------------
     }
}
--------------------------------------------------------------------------------
T.RTitleUserPersonal
Name
DateLines
3465.1Working...GEMGRP::MONTELEONETue Feb 25 1997 13:237
    
    
    I'll take a look...
    
    
    Bob
    
3465.2Maybe it depends on how you "step into" the CLock constructor.WIDTH::MDAVISMark Davis - compiler maniacTue Feb 25 1997 13:4920
I'm not agile with the vms debugger, so I tried the program on unix.

The 3 initialization expressions

CLock( CCntSemaphore & rSem ) : 
        m_lSemCount( 0 ), m_lFlags( 0 ),m_rSemaphore( rSem )

are done as part of the execution of CLock.  If I say "stop in CLock",
the debugger sets a breakpoint after the prolog and BEFORE any
of the interesting code for CLock. I.e., "m_rSemaphore( rSem )" has
not been performed yet.  So, if I examine m_rSemaphore, it has some
uninitialized value.

	If I step to the end of the constructor just before it returns,
then m_rSemaphore has been initialized and has the expected value.


	The reason that "stop in" stops before the init expressions is
so you can look around before anything has been done, or so you can trace
through their execution....
3465.3GEMGRP::MONTELEONETue Feb 25 1997 17:207
    
    
    The symbol table looks okay. Mark Arsenault of the VMS debug team is
    investigating now...
    
    
    Bob
3465.4Analysis...GEMGRP::MONTELEONEWed Feb 26 1997 18:39104
    
    
    Mark A. and I have gotten to the bottom of this (thanks from me to Judy 
    for C++ consulting).
    
    On UNIX, there is explicit support in the symbol table for C++
    references. The front end generates calls to GEM_TD_DEF_CXX_REFERENCE
    which gets correctly translated to the appropriate representation in 
    the Third Eye Symbol Table. 
    
    On VMS, there is no such explicit support in the symbol table (i.e.
    there is no specific DST for C++ references). Also, the front end is
    not generating calls to GEM_TD_DEF_CXX_REFERENCE on VMS. 
    The front end needs to either 1) generate a call to 
    GEM_TD_DEF_POINTER or 2) enable calls to GEM_TD_DEF_CXX_REFERENCE,
    at which point I can treat a GEM_TD_DEF_CXX_REFERENCE tdi like a pointer 
    TDI on VMS (at least for the time being). 
    
    A longer term solution would be to have the debug team design an explict 
    C++ reference TDI, which I would generate as a result of the front end
    calling GEM_TD_DEF_CXX_REFERENCE - like what occurs on UNIX today.
    
    Mark was able to produce a simpler example with which to work:
    
    -------------------------------------------------------------------
    
    int c=11;
    
    struct A
        {
        int x;
        int y;
    
        A() : x(c++), y(c++) {};
        };
    
    struct B
        {
        int i;
        int j;
        A & a;
    
        B( A & p_a ) : i(3), j(4), a( p_a ) {};
        };
    
    struct C
        {
        int k;
        A a;
    
        C( A p_a ) : k(5), a( p_a ) {};
        };
    
    struct D
        {
        int l;
        A * a;
    
        D( A p_a ) : l(6), a( &p_a ) {};
        };
    
    main()
        {
        A a;
        B b( a );
        C c( a );
        D d( a );
        b.i = 1;
        b.j = 2;
        }
    
    ---------------------------------------------------------------------------
    
    In main, step to after the declarations and EXAMINE a,b,c,d.  Note that
    d is correct and b is not.  Dump the DSTs.  You see that d.a is described as
    a pointer to an A, whereas b.a is described as an A.  b.a should be
    described as a pointer to an A.
    
    From a TDI dump perspective, CLASS_MEM_TYPE for a should point to
    either a POINTER or CXX_REFERENCE tdi, based upon which approach,
    above is adopted, rather than the CLASS tdi for B directly.
    
        CLASS TDI B  : &ADDRESS=0087E9A8, LOCATOR={11:0-18:4},
                 NEXT=0087E9E8, CLASS
                CLASS_LIST_HEAD=0087EEE0, CLASS_LIST_TAIL=0087F230;
            CLASS_MEM TDI i  : &ADDRESS=0087EEE0, LOCATOR={13:8},NEXT=0087EF18, CL
                     CLASS_MEM_BYTE_OFFSET=[INT32=0],CLASS_MEM_BIT_OFFSET=[INT32=0
                    CLASS_MEM_ACCESS=&PUBLIC;
            CLASS_MEM TDI j  : &ADDRESS=0087EF18, LOCATOR={14:8},NEXT=0087EF50, CL
                     CLASS_MEM_BYTE_OFFSET=[INT32=4],CLASS_MEM_BIT_OFFSET=[INT32=0
                    CLASS_MEM_ACCESS=&PUBLIC;
            CLASS_MEM TDI a  : &ADDRESS=0087EF50, LOCATOR={15:6-8},NEXT=0087EF88,
                               CLASS_MEM_TYPE=A0087E968,
    					      *********	
    
                     CLASS_MEM_BYTE_OFFSET=[INT32=8],
                     CLASS_MEM_BIT_OFFSET=[INT32=0],CLASS_MEM_SIZE=[INT32=32],
                    CLASS_MEM_ACCESS=&PUBLIC;
    
    
    
    Bob
    
    
3465.5KERNEL::PULLEYCome! while living waters flowMon Mar 03 1997 14:0110
    Thanks all involved for that.
    
    Does this mean that CXX on VMS might change to do the same with those
    references as UNIX?
    The customer believes it used to work on earlier versions--does that
    fit in to the work you've done--or is he perhaps mistaken?
    
    Thanks,
    Steve.
    
3465.6GEMGRP::MONTELEONEMon Mar 03 1997 15:5325

    >>Does this mean that CXX on VMS might change to do the same with those
    >>references as UNIX?

      Yes. There are a couple of different approaches to resolve this problem,
      described in the previous note. One approach is more complete than the 
      other, but both will solve the customer's problem.


   >>The customer believes it used to work on earlier versions--does that
   >>fit in to the work you've done--or is he perhaps mistaken?


      The C++ debugging support was completely enhanced and redone recently.
      It is possible, though, that this piece of functionality was working
      in an earlier release and now doesn't because of the bug reported here.


      The customer is probably not mistaken if he/she recalls that it used 
      to work...


      Bob