This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

shlibs/1844: Fortran common block symbols not resolved properly when loading shared libraries


>Number:         1844
>Category:       shlibs
>Synopsis:       Fortran common block symbols not resolved properly when loading shared libraries
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 11 17:58:01 UTC 2005
>Closed-Date:
>Last-Modified:
>Originator:     jeff.webb@nta-inc.net
>Release:        gdb-6.3,  gdb-6.1-debian, gdb-5.3.90-0.20030710.41rh
>Organization:
>Environment:
OS: Fedora Core 1 (Linux 2.4.22-rtl3.2-pre3 i686 athlon i386 GNU/Linux)

GCC: Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.3.2 20031022 (Red Hat Linux 3.3.2-1)

GDB: i686-pc-linux-gnu (compiled from 6.3 source)

Other tested environments:  Same results with default FC1 gdb-5.3.90 on the above machine, and with debian/unstable gdb-6.1 on a PIII machine.
>Description:
I haven't been able to get gdb to work properly when debugging fortran code that uses common blocks when the code is loaded as a shared library.  I've attached a very simple example that illustrates the problem.

The main program establishes a common block /cb/ that contains three integer variables (i,j,k).  The main program then calls two subroutines (sub1 and sub2), which print out the values of the variables in the common block.  The only difference between sub1 and sub2 is that sub1 is located in the top-level source file called "main.f", and sub2 is located in a separate source file called "sub.f".

If I create a statically linked program, the program executes correctly, and gdb displays the correct values for the common block variables found in sub1 and sub2.

If I create a dynamically linked program, the program executes correctly, but gdb has some problems when the common block is examined from sub2.  The first problem is that the "cb_" symbol for the common block only gets mapped to the "cb_" symbol in main if I run gdb with '--readnow', or if I put a breakpoint in sub1 first, and then examine the common block from sub2.  I can work around this problem with the '--readnow' flag.

The second problem is causing me more trouble.  Although the '--readnow' flag causes the common block 'cb_' to get resolved properly, the members of the common block (i,j,k) are not.  They still point to an address in the memory associated with the shared library, and not the main program, where the 'real' common block is located.

I have been tinkering with gdb's source code, trying to track down the problem, but understanding how everything works is a little daunting.  It appears that 'cb_' gets fixed up because it is a global variable, but the i, j, k seem to be locals and don't get relocated when gdb fixes up 'cb_'.

I was hoping someone who understands the code better might see the root of the problem, and point me in the direction of a fix.

main.f:

      program main
      common /cb/ i, j, k
      integer i, j, k
      i = 1
      j = 2
      k = 3
      call sub1
      call sub2
      end

      subroutine sub1
      common /cb/ i, j, k
      integer i, j, k
      print *,i,j,k
      return
      end

sub.f:

      subroutine sub2
      common /cb/ i, j, k
      integer i, j, k
      print *,i,j,k
      return
      end

Makefile:

all: libsub.so main main_static

main_static: main.f sub.f
	g77 -g main.f sub.f -o main_static

main: main.f
	g77 -g main.f -o main -L./ -lsub -fPIC

libsub.so: sub.f
	g77 -g sub.f -o libsub.so -shared -fPIC

clean:
	rm -f *~ *.so main main_static
>How-To-Repeat:
See Description.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]