now impossible to debug code that uses PETSc shared libraries?

[Aron Ahmadia]

this fixed yet?  I can test out a petsc-dev build on my MBP and see if I've
got the same issues.

~A

On Fri, May 2, 2008 at 2:21 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

> apple
>
>
> On May 1, 2008, at 11:23 AM, Satish Balay 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
> > >
> > >
> > >
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20080502/7e697f74/attachment.html>