now impossible to debug code that uses PETSc shared libraries?

[Satish Balay]

What machine is this?

Its been working forever for me on linux.

Satish

---------------------------------------------------
asterix:/home/balay/spetsc/src/ksp/ksp/examples/tutorials>ls /home/balay/spetsc/asterix/lib/
foo                 libpetscdm.so   libpetscmat.so   libpetsc.so    libpetscvec.so
libpetsccontrib.so  libpetscksp.so  libpetscsnes.so  libpetscts.so
asterix:/home/balay/spetsc/src/ksp/ksp/examples/tutorials>

 <removed .a files>

asterix:/home/balay/spetsc/src/ksp/ksp/examples/tutorials>ldd ex2
        linux-gate.so.1 =>  (0x00110000)
        libpetscksp.so => /home/balay/spetsc/asterix/lib/libpetscksp.so (0x00111000)
        libpetscdm.so => /home/balay/spetsc/asterix/lib/libpetscdm.so (0x00374000)
        libpetscmat.so => /home/balay/spetsc/asterix/lib/libpetscmat.so (0x00493000)
        libpetscvec.so => /home/balay/spetsc/asterix/lib/libpetscvec.so (0x00838000)
        libpetsc.so => /home/balay/spetsc/asterix/lib/libpetsc.so (0x00a55000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x00bf9000)
        liblapack.so.3 => /usr/lib/atlas/liblapack.so.3 (0x00cf5000)
        libblas.so.3 => /usr/lib/atlas/libblas.so.3 (0x02a29000)
        libm.so.6 => /lib/libm.so.6 (0x009a0000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x009c9000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00a0e000)
        libgfortran.so.1 => /usr/lib/libgfortran.so.1 (0x0600e000)
        libc.so.6 => /lib/libc.so.6 (0x078a3000)
        libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x009e2000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x009e4000)
        libdl.so.2 => /lib/libdl.so.2 (0x00a00000)
        /lib/ld-linux.so.2 (0x00a38000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x00a05000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00a08000)
asterix:/home/balay/spetsc/src/ksp/ksp/examples/tutorials>gdb ex2
GNU gdb Red Hat Linux (6.6-45.fc8rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) b MatMult
Function "MatMult" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (MatMult) pending.
(gdb) r
Starting program: /home/balay/hg-repo/petsc-dev/src/ksp/ksp/examples/tutorials/ex2 
[Thread debugging using libthread_db enabled]
Breakpoint 2 at 0x6250f3: file matrix.c, line 1690.
Pending breakpoint "MatMult" resolved
[New Thread -1208318272 (LWP 30748)]
[Switching to Thread -1208318272 (LWP 30748)]

Breakpoint 2, MatMult (mat=0x9aabc58, x=0x9a9c888, y=0x9a9d698) at matrix.c:1690
1690         PetscFunctionBegin;
Missing separate debuginfos, use: debuginfo-install atlas.i386 gcc.i386 glibc.i686 libX11.i386 libXau.i386 libXdmcp.i386 libxcb.i386
(gdb) list
1685  @*/
1686  PetscErrorCode PETSCMAT_DLLEXPORT MatMult(Mat mat,Vec x,Vec y)
1687  {
1688    PetscErrorCode ierr;
1689    
1690      PetscFunctionBegin;
1691      PetscValidHeaderSpecific(mat,MAT_COOKIE,1);
1692      PetscValidType(mat,1);
1693      PetscValidHeaderSpecific(x,VEC_COOKIE,2);
1694      PetscValidHeaderSpecific(y,VEC_COOKIE,3); 
(gdb) 

On Thu, 1 May 2008, Barry Smith wrote:

> 
>  It seems to now be impossible to debug in code that uses PETSc shared
> libraries
> 
> 	        fi; \
> 	        if [ "$$flag" != "" ]; then \
>                echo "building $$LIBNAME.${SL_LINKER_SUFFIX}"; \
>                  ${RM} -f ${INSTALL_LIB_DIR}/tmp-petsc-shlib/*; \
> 	          cd  ${INSTALL_LIB_DIR}/tmp-petsc-shlib; \
> 	          ${AR} x ${INSTALL_LIB_DIR}/$$LIBNAME.${AR_LIB_SUFFIX}; \
>                  cd $$cwd;\
> 	          ${OMAKE} LIBNAME=$$LIBNAME
> SHARED_LIBRARY_TMPDIR=${INSTALL_LIB_DIR}/tmp-petsc-shlib shared_arch; \
> 	        fi; \
> 	      fi; \
> 	    done; \
> 	    ${RM} -rf ${INSTALL_LIB_DIR}/tmp-petsc-shlib; \
> 	  fi
> 
> 
> In the debugger, of course, one gets
> warning: Could not find object file
> "/Users/bsmith/Src/petsc-dev-for-fixes/shit/lib/tmp-petsc-shlib/bvec2.o" - no
> debug information available for "bvec2.c".
> 
> 
> since the .o files are removed the debugger cannot find any debug information.
> 
> Is this intentional? Seems pretty terrible to give up debugging just to use
> shared libraries.
> 
>   Barry
> 
> 
>