| 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....
|
|
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
|
|
>>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
|