Conference turris::decladebug

899.0. "Invisible extern type in C++, but not in C" by CXXC::MJHANS (Matthew Hanselman, DEC C/C++) Tue Mar 25 1997 16:03

    This is a regression between 4.0-30 and 4.0-33.
    
    With shared objects, an external variable (whose type is a BLISS type,
    I think) is no longer visible in a C++ file.  Unfortunately, I cannot
    narrow this down to a simple test case to post here.
    
    To reproduce this problem, debug a copy of the V6.0 C++ compiler and
    stop in a C++ file -- stop in the function "walk_scope()".  Trying to 
    examine the variable "gem_db_g_debug" works for 4.0-30, but not for
    4.0-33.  Note that if you move to the scope of a C file, the type
    becomes visible.
    
    This should wait until somebody in the ladebug group gets VMS proxies
    set up so that they can use a compiler out of our build tree.  Talk to
    Bevin for details.
    
    Here's a command playback file to use:
    
    =========================================================================
    
    stop
    in walk_scope
    run tmp.cxx
    # In a C++ file
    p gem_db_g_debug
    # Get to a C file
    up ; up ; up ; up
    p gem_db_g_debug
    
    =========================================================================
    
    Working version:
    
    Welcome to the Ladebug Debugger Version 4.0-30
    ------------------ 
    object file name: /usr/users/mjhans/cpri/exxalphaosf/bl36/exe/exx 
    Reading symbolic information ...done
    (ladebug) stop in walk_scope
    [#1: stop in void walk_scope(a_scope_ptr) ]
    (ladebug) run tmp.cxx
    [1] stopped at [void walk_scope(a_scope_ptr):255 0x6ff9e510]
        255     walk_scope_pragmas   (scope);
    (ladebug) p gem_db_g_debug
    335674744
    (ladebug) up ; up ; up ; up
    >1  0x6ff9e3b8 in me_driver(module_result={ ... })
    /usr/users/mjhans/cpri/src/edg-meg/me.cxx:204
        204     walk_scope(il_header.primary_scope);
    >2  0x6ffcb50c in dec_exx_back_end_one_o_file(object_file_fcb=0x0)
    /usr/users/mjhans/cpri/src/edg-dcg/compile.cxx:1389
       1389     me_driver(module_il);
    >3  0x6ffcad04 in dec_exx_back_end()
    /usr/users/mjhans/cpri/src/edg-dcg/compile.cxx:1127
       1127         dec_exx_back_end_one_o_file(
    >4  0x6fe27fe4 in edg_main(argc=2, argv=0x11fff2e0="\210T\374o
    7\370\177\020-\370\177") /usr/users/mjhans/cpri/src/edg-src/cfe.c:136
        136         dec_exx_back_end();
    (ladebug) p gem_db_g_debug
    335674744
    
    =========================================================================
    Non-working version:
    
    Welcome to the Ladebug Debugger Version 4.0-33
    ------------------ 
    object file name: /usr/users/mjhans/cpri/exxalphaosf/bl36/exe/exx 
    Reading symbolic information ...done
    (ladebug) stop in walk_scope
    [#1: stop in void walk_scope(a_scope_ptr) ]
    (ladebug) run tmp.cxx
    [1] stopped at [void walk_scope(a_scope_ptr):255 0x6ff9e510]
        255     walk_scope_pragmas   (scope);
    (ladebug) p gem_db_g_debug
    Symbol gem_db_g_debug not visible in current scope.
    Error: no value for gem_db_g_debug
    (ladebug) up ; up ; up ; up
    >1  0x6ff9e3b8 in me_driver(module_result=class { ... })
    /usr/users/mjhans/cpri/src/edg-meg/me.cxx:204
        204     walk_scope(il_header.primary_scope);
    >2  0x6ffcb50c in dec_exx_back_end_one_o_file(object_file_fcb=0x0)
    /usr/users/mjhans/cpri/src/edg-dcg/compile.cxx:1389
       1389     me_driver(module_il);
    >3  0x6ffcad04 in dec_exx_back_end()
    /usr/users/mjhans/cpri/src/edg-dcg/compile.cxx:1127
       1127         dec_exx_back_end_one_o_file(
    >4  0x6fe27fe4 in edg_main(argc=2, argv=0x11fff2e0="\210T\374o
    7\370\177\020-\370\177") /usr/users/mjhans/cpri/src/edg-src/cfe.c:136
        136         dec_exx_back_end();
    (ladebug) p gem_db_g_debug
    335674744
    
    
    
    							- Matt

Which compiler did you use when trying out the Ladebug 4.0-30?
Were both tests done using the new compiler, or an older one?

I ask because we saw a similar occurrance between C & C++ when
a variable was declared extern  C.  In this case we no longer
had symbolic info in the C++ file for this variable (and ladebug
currently doesn't search for symbols cross language boundaries well).


-Steve

    This is with an older compiler, V5.5-010.  I'll try poking around a
    little more and see if I can figure out anything else more useful.
    
    							- Matt

Can you post or e-mail me the output of stdump on your binary | grep
problem-sybol ?

I've made some changes with dynamic symbols recently...

    The executable is made up of 6 shared objects, and "gem_db_g_debug" is
    seen in only one of of those objects (libgem.so):
    
    % stdump libgem.so | grep gem_db_g_debug
    3659. (file 105) (0x7ffd8758) gem_db_g_debug Global     Bss        [ 1] int
    
    The 'C' declaration of gem_db_g_debug is:
    
    	typedef struct GEM_TX_FILE GEM_TX_FILE;
    	extern GEM_TX_FILE* gem_db_g_debug;
    
    And C++ is:
    
    	class GEM_TX_FILE;
    	extern "C" {
    	extern GEM_TX_FILE* gem_db_g_debug;
    	}
    
    You can see "gem_db_g_debug" while in another shared object if it is a
    C file, but not C++  -- even when both of these files are in the same 
    shared object.
    
    But I can't make this happen by hand.....
    
    								- Matt

From what I can see, it is not the recent changes I was thinking of.

Tim

I've added this problem to the C++ tracking list.

    This problem (at least, the case in question) appears to have been
    fixed in ladebug 4.0-36.
    
    							- Matt