Dynamically Loaded Shared Libraries and dbx

Dynamically Loaded Shared Libraries and dbx

Post by Brent Lambe » Wed, 06 Jan 1993 05:06:47


Program and libraries have proper common resolution, but dbx doesn't.


Mixed C & FORTRAN main executable exports a common block.
FORTRAN shared library imports the common block.
Main executable dynamically loads shared library (load & loadbind),
then invokes a subroutine in the shared library (exported, of course).
The subroutine references the exported common in the process of
performing it's function.


This program works fine!  Even in dbx.  But dbx doesn't work fine.

While stepping through a subroutine in the library, I attempt to print
the value of a common variable exported from the main executable, and
dbx gives a value which I know not to be true, and which would break
the program if it were.

Here's a partial transcript (with the names changed for clarity) to
show you what I mean.  The main characters are:
    GLOBVAR, a common variable which is exported from the main executable
    LOCVAR, a local variable (in the subroutine)

stopped in file1 at line 96 in file "file1.f"
   96         LOCVAR = GLOBVAR
0 -1
(dbx) n
stopped in file1 at line 97 in file "file1.f"
   97         IPTNDI = 0
51195 -1
(dbx) whatis LOCVAR
 integer*4 locvar
(dbx) whatis GLOBVAR
 integer*4 globvar


I believe that the de* is looking at a local copy of the common,
rather than the exported copy that the actual code uses.  What I'm
looking for is a way to tell dbx to look at the same common the
program uses.

Since this is a large project, with more than 50 shared libraries,
hundreds of common blocks, thousands of source files, and half a dozen
developers, I'm looking for a general debugging solution which doesn't
require code changes.

I'll summarize to the net.  Thanks.

The above statements are not the opinions or policies of SPSS Inc.
The above statements may not be the opinions of Brent Lambert.
The first disclaimer is a policy of SPSS Inc.
Subsequent disclaimers are probably the opinion of Brent Lambert.


1. Unresolved references in dynamically loaded shared library (SunOS 4.1.3)


I am involved in developing an application which requires dynamically loading
and executing functions from shared libraries which don't necessarily exist at
the time the application driver itself is linked.  When these functions in turn
have calls to functions in other shared libraries, ld.so successfully resolves
these references as long their definitions reside in libraries which were
scanned by ld at the time the application driver was linked (system libraries,
for example).

The problem I have run into is that some of these function definitions reside
in other shared libraries which have also been dynamically loaded.  In this
case (unless the references and the definition reside in the same library),
ld.so has no knowledge of these dynamically loaded libraries and therefore
cannot search them.

Is there a way to augment this list of dynamic dependencies at run time so that
the search performed by ld.so can be extended to these dynamically loaded
libraries?  Investigation of the data structures defined in /usr/include/link.h
seems to indicate that there is indeed a way this can be done, if the the
programmer has knowledge of the dynamic linking mechanism beyond what is
available from the Sun manuals.

I would be grateful for any comments or pointers to related material.


   |   Texas Instruments Inc.    TI MSG: RWES                  |
   |   PO Box 149149, MS 2201     Voice: (512) 250-7372        |
   |___Austin, TX 78714-9149________Fax: (512) 250-7104________|

2. problems with 98 and Solaris setup

3. Controlling exports in Dynamically loaded shared libraries

4. --dhcp server

5. dynamically loading shared libraries

6. RS40b/buggy getty?

7. Calling Linux-PAM from a dynamically loaded shared library

8. A Tool Challenge...which lang is best?

9. Is there a way to load share library dynamically in C on Unix platform?

10. Dynamically Loading a Shared Library on HP-UX

11. Shared library loading shared library.

12. error in loading shared libraries: libXmu.so.6: cannot open shared object