now impossible to debug code that uses PETSc shared libraries?

[Matthew Knepley]

I can also debug just fine or I would scream bloody murder.

  Matt

On Thu, May 1, 2008 at 10:23 AM, Satish Balay <balay at mcs.anl.gov> wrote:
> 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
>  >
>  >
>  >
>
>



-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener