From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: pedwards@disaster.jaj.com Cc: gdb@sources.redhat.com Subject: Re: fwd: fixing some FIXMEs Date: Tue, 09 Jan 2001 00:29:00 -0000 Message-id: <200101090829.DAA10040@indy.delorie.com> References: <20010108210432.A32378@disaster.jaj.com> X-SW-Source: 2001-01/msg00021.html > Date: Mon, 8 Jan 2001 21:04:32 -0500 > From: Phil Edwards > > I ran into these two FIXMEs in the top-level configury. The one which > tests the host is moved into the per-host section, and the one which sets > up GDB_TK is moved into the per-target section. > > Opinions? Comments? I'd need to see the regenerated configure script to judge whether this is okay for the DJGPP port. (I don't have Autoconf installed and don't have time to futz with it, sorry.) >From fnasser@redhat.com Tue Jan 09 03:25:00 2001 From: Fernando Nasser To: Phil Edwards Cc: gdb@sources.redhat.com Subject: Re: _status: no such variable Date: Tue, 09 Jan 2001 03:25:00 -0000 Message-id: <3A5AF4D3.67766B18@redhat.com> References: <20010108234026.A450@disaster.jaj.com> X-SW-Source: 2001-01/msg00022.html Content-length: 2373 Phil Edwards wrote: > > Firing up current CVS's insight hangs the source window, with the console > window containing: > No matter what I do I cannot reproduce this. It just works fine for me under several different circumstances. And I have it on different machines, different OS versions... And I've been just talking with some other folks who just built it all right. Furthermore, this stack trace describes an impossible situation. "_status" is where the Source Window stores the name of the label widget that is used for status and help information (at the bottom). Regardless of the success or not of the creation of this widget the variable should exist. "no such variable" is just absurd. There are two possibilities remaining: 1) Your cvs checkout went terribly wrong. A fresh checkout should fix it. 2) You are loading some program (you called GDB with an executable name in the command line). Something went wrong with the symbol reading and GDB did a longjump in some uncaught situation (I thought we got rid of those though). Please try opening GDB without specifying a file. If nothing of the above works, you can try deleting your ~/.gdbtkinit, rebuilding the whole tree from scratch (something went wrong with "configure"?), changing the compiler version etc. It just works. If you are still having problems feel free to send me an e-mail. Good luck, Fernando > can't read "_status": no such variable > while executing > "$_status configure -text $saved_msg" > (object "::.srcwin0.srcwin" method "::SrcWin::set_status" body line 10) > invoked from within > "set_status $message" > (object "::.srcwin0.srcwin" method "::SrcWin::set_execution_status" body line 69) > invoked from within > "set_execution_status $line $addr" > (object "::.srcwin0.srcwin" method "::SrcWin::location" body line 12) > invoked from within > "$src location BROWSE_TAG [list $linespec]" > (procedure "::SrcWin::point_to_main" body line 9) > invoked from within > "SrcWin::point_to_main" > (procedure "gdbtk_tcl_preloop" line 13) > invoked from within > "gdbtk_tcl_preloop" > (gdb) > -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 >From fnasser@redhat.com Tue Jan 09 03:41:00 2001 From: Fernando Nasser To: Phil Edwards Cc: gdb@sources.redhat.com, Insight List Subject: Re: shared libraries in tcl/tk parts of insight Date: Tue, 09 Jan 2001 03:41:00 -0000 Message-id: <3A5AF877.2B93F0EF@redhat.com> References: <20010109001927.A600@disaster.jaj.com> X-SW-Source: 2001-01/msg00023.html Content-length: 8313 Thanks Phil. Your patch will be very useful as a reference to get this fixed. This things work better with Libtool though. Fernando Phil Edwards wrote: > > Okay, last bug report for a few days, I promise. :-) I take it that > --enable-shared isn't a common configuration for Insight? (I tried naming > specific tools and libraries in the --enable-shared= argument, but that > doesn't work like I thought it did.) > > While trying to build a unified gcc+gdb+binutils tree on i686-pc-linux-gnu: > > rm -f libitcl3.0.so > gcc -shared -o libitcl3.0.so itcl_bicmds.o itcl_class.o itcl_cmds.o > itcl_ensemble.o itcl_linkage.o itcl_methods.o itcl_migrate.o itcl_objects.o > itcl_obsolete.o itcl_parse.o itcl_util.o > ranlib libitcl3.0.so > ranlib: libitcl3.0.so: File format not recognized > gmake[2]: *** [libitcl3.0.so] Error 1 > gmake[2]: Leaving directory `/home/pme/build/build-2001-01-08/itcl/itcl/unix' > gmake[1]: *** [all] Error 1 > gmake[1]: Leaving directory `/home/pme/build/build-2001-01-08/itcl' > gmake: *** [all-itcl] Error 2 > > This occurs when --enable-shared was passed to the top-level configure. > The libraries are being built correctly, but the various Makefile's blindly > call ranlib on them after the build, and then they will try to do so again > during installation. > > This happens in a number of tcl/tix/tk/itcl places. Sometimes the Makefiles > have rules to correctly call ranlib or not during the build, but do it > again anyhow during the installation. There are correct "RANLIB = :" > definitions created, but they are overridden by the top-level make. > > This patch gets me through things corectly. It isn't suitable for > application (it makes assumptions about filename endings), but at least > points out where the problems occur. > > Also, there are issues with calling the newly-built tclsh during install. > With --enable-shared LD_LIBRARY_PATH must be used (or libtool!). > Also, TCL_BIN_DIR wasn't being replaced by configure, and would remain > @TCL_BIN_DIR@ in the Makefile. I touch'ed, I autoconf'ed, I grep'ed; > it just would not be looked at by config.status. Using any name other > than TCL_BIN_DIR worked fine. I don't know why. > > Phil > [not subscribed to this list] > > Index: itcl/itcl/unix/Makefile.in > =================================================================== > RCS file: /cvs/src/src/itcl/itcl/unix/Makefile.in,v > retrieving revision 1.1.1.1 > diff -u -3 -r1.1.1.1 Makefile.in > --- Makefile.in 2000/02/07 00:19:46 1.1.1.1 > +++ Makefile.in 2001/01/09 04:39:32 > @@ -193,7 +193,7 @@ > @ITCL_LIB_FILE@: $(OBJS) > rm -f $(ITCL_LIB_FILE) > @MAKE_LIB@ > - $(RANLIB) $(ITCL_LIB_FILE) > + case $(ITCL_LIB_FILE) in *.a) $(RANLIB) $(ITCL_LIB_FILE) ;; esac > > itclsh: tclAppInit.o $(ITCL_LIB_FILE) @TCL_LIB_FULL_PATH@ > $(CC) @LD_FLAGS@ tclAppInit.o @ITCL_BUILD_LIB_SPEC@ \ > @@ -213,7 +213,7 @@ > @$(MKINSTALLDIRS) $(LIB_INSTALL_DIR) $(BIN_INSTALL_DIR) > @echo "Installing $(ITCL_LIB_FILE)" > @$(INSTALL_DATA) $(ITCL_LIB_FILE) $(LIB_INSTALL_DIR)/$(ITCL_LIB_FILE) > - @(cd $(LIB_INSTALL_DIR); $(RANLIB) $(ITCL_LIB_FILE)) > + @case $(ITCL_LIB_FILE) in *.a) (cd $(LIB_INSTALL_DIR); $(RANLIB) $(ITCL_LIB_FILE));; esac > chmod 555 $(LIB_INSTALL_DIR)/$(ITCL_LIB_FILE) > @echo "Installing itclsh" > $(INSTALL_PROGRAM) itclsh $(BIN_INSTALL_DIR)/itclsh$(VERSION) > Index: itcl/itk/unix/Makefile.in > =================================================================== > RCS file: /cvs/src/src/itcl/itk/unix/Makefile.in,v > retrieving revision 1.1.1.1 > diff -u -3 -r1.1.1.1 Makefile.in > --- Makefile.in 2000/02/07 00:19:46 1.1.1.1 > +++ Makefile.in 2001/01/09 04:39:32 > @@ -226,7 +226,7 @@ > @ITK_LIB_FILE@: ${OBJS} > rm -f $(ITK_LIB_FILE) > @MAKE_LIB@ > - $(RANLIB) $(ITK_LIB_FILE) > + case $(ITK_LIB_FILE) in *.a) $(RANLIB) $(ITK_LIB_FILE) ;; esac > > itkwish: tkAppInit.o $(ITK_LIB_FILE) @TCL_LIB_FULL_PATH@ @TK_LIB_FULL_PATH@ \ > @ITCL_LIB_FULL_PATH@ > @@ -253,7 +253,7 @@ > @$(MKINSTALLDIRS) $(LIB_INSTALL_DIR) $(BIN_INSTALL_DIR) > @echo "Installing $(ITK_LIB_FILE)" > @$(INSTALL_DATA) $(ITK_LIB_FILE) $(LIB_INSTALL_DIR) > - @(cd $(LIB_INSTALL_DIR); $(RANLIB) $(ITK_LIB_FILE)) > + @case $(ITK_LIB_FILE) in *.a) (cd $(LIB_INSTALL_DIR); $(RANLIB) $(ITK_LIB_FILE));; esac > @chmod 555 $(LIB_INSTALL_DIR)/$(ITK_LIB_FILE) > @echo "Installing itkwish" > $(INSTALL_PROGRAM) itkwish $(BIN_INSTALL_DIR)/itkwish$(VERSION) > Index: tcl/unix/Makefile.in > =================================================================== > RCS file: /cvs/src/src/tcl/unix/Makefile.in,v > retrieving revision 1.1.1.1 > diff -u -3 -r1.1.1.1 Makefile.in > --- Makefile.in 1999/11/09 01:28:44 1.1.1.1 > +++ Makefile.in 2001/01/09 04:39:38 > @@ -449,7 +449,7 @@ > done; > @echo "Installing $(TCL_LIB_FILE)" > @$(INSTALL_DATA) $(TCL_LIB_FILE) $(LIB_INSTALL_DIR)/$(TCL_LIB_FILE) > - @(cd $(LIB_INSTALL_DIR); $(RANLIB) $(TCL_LIB_FILE)) > + @case $(TCL_LIB_FILE) in *.a) (cd $(LIB_INSTALL_DIR); $(RANLIB) $(TCL_LIB_FILE));; esac > @chmod 555 $(LIB_INSTALL_DIR)/$(TCL_LIB_FILE) > @echo "Installing tclsh" > @$(INSTALL_PROGRAM) tclsh $(BIN_INSTALL_DIR)/tclsh > Index: tix/unix/tk8.0/Makefile.in > =================================================================== > RCS file: /cvs/src/src/tix/unix/tk8.0/Makefile.in,v > retrieving revision 1.1.1.1 > diff -u -3 -r1.1.1.1 Makefile.in > --- Makefile.in 2000/02/07 00:19:29 1.1.1.1 > +++ Makefile.in 2001/01/09 04:39:39 > @@ -67,7 +67,7 @@ > # > TCL_SRC_DIR = @TCL_SRC_DIR@ > TCL_GENERIC_DIR = $(TCL_SRC_DIR)/generic > -TCL_BIN_DIR = @TCL_BIN_DIR@ > +TCL_BIN_DIR = @TCLBINDIR_VARIABLE@ > > # Location of the Tk 8.0 source directory. > # > @@ -84,6 +84,7 @@ > > RUN_TCLSH = TCL_LIBRARY=$(TCL_SRC_DIR)/library \ > TK_LIBRARY=$(TK_SRC_DIR)/library \ > + LD_LIBRARY_PATH=$(TCL_BIN_DIR):${LD_LIBRARY_PATH} \ > $(TCL_BIN_DIR)/tclsh > > > Index: tix/unix/tk8.0/configure.in > =================================================================== > RCS file: /cvs/src/src/tix/unix/tk8.0/configure.in,v > retrieving revision 1.1.1.1 > diff -u -3 -r1.1.1.1 configure.in > --- configure.in 2000/02/07 00:19:29 1.1.1.1 > +++ configure.in 2001/01/09 04:39:40 > @@ -144,7 +144,7 @@ > > # CYGNUS LOCAL: This used to get TCL_BIN_DIR from TCL_SRC_DIR, which > # only works when srcdir == objdir > -TCL_BIN_DIR=../../../tcl/unix > +TCLBINDIR_VARIABLE=../../../tcl/unix > > #-------------------------------------------------------------------- > # See if there was a command-line option for where Tk is; if > @@ -221,7 +221,7 @@ > # Makefile. > #-------------------------------------------------------------------- > > -file=$TCL_BIN_DIR/tclConfig.sh > +file=$TCLBINDIR_VARIABLE/tclConfig.sh > . $file > CC=$TCL_CC > SHLIB_CFLAGS=$TCL_SHLIB_CFLAGS > @@ -387,7 +387,7 @@ > AC_SUBST(TCL_LIBS) > AC_SUBST(TCL_VERSION) > AC_SUBST(TCL_SRC_DIR) > -AC_SUBST(TCL_BIN_DIR) > +AC_SUBST(TCLBINDIR_VARIABLE) > AC_SUBST(TCL_LIB_FULL_PATH) > AC_SUBST(TK_BUILD_LIB_SPEC) > AC_SUBST(TK_LIBS) > Index: tk/unix/Makefile.in > =================================================================== > RCS file: /cvs/src/src/tk/unix/Makefile.in,v > retrieving revision 1.1.1.1 > diff -u -3 -r1.1.1.1 Makefile.in > --- Makefile.in 2000/02/07 00:19:30 1.1.1.1 > +++ Makefile.in 2001/01/09 04:39:41 > @@ -386,7 +386,7 @@ > done; > @echo "Installing $(TK_LIB_FILE)" > @$(INSTALL_DATA) $(TK_LIB_FILE) $(LIB_INSTALL_DIR)/$(TK_LIB_FILE) > - @(cd $(LIB_INSTALL_DIR); $(RANLIB) $(TK_LIB_FILE)) > + @case $(TK_LIB_FILE) in *.a) (cd $(LIB_INSTALL_DIR); $(RANLIB) $(TK_LIB_FILE));; esac > @chmod 555 $(LIB_INSTALL_DIR)/$(TK_LIB_FILE) > @echo "Installing wish" > @$(INSTALL_PROGRAM) wish $(BIN_INSTALL_DIR)/wish -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 >From jtc@redback.com Tue Jan 09 10:34:00 2001 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com Subject: testsuite timeouts Date: Tue, 09 Jan 2001 10:34:00 -0000 Message-id: <5mr92cwp4x.fsf@jtc.redback.com> X-SW-Source: 2001-01/msg00024.html Content-length: 218 I'm running the GDB testsuite on a pretty slow box --- a 16MHz 68030 --- and getting a lot of failures due to timeouts. Is there a way to increase the timeout value? --jtc -- J.T. Conklin RedBack Networks >From jtc@redback.com Tue Jan 09 11:24:00 2001 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com Subject: Re: testsuite timeouts Date: Tue, 09 Jan 2001 11:24:00 -0000 Message-id: <5mr92cv8cw.fsf@jtc.redback.com> References: <5mr92cwp4x.fsf@jtc.redback.com> X-SW-Source: 2001-01/msg00025.html Content-length: 518 >>>>> "jtc" == J T Conklin writes: jtc> I'm running the GDB testsuite on a pretty slow box --- a 16MHz 68030 jtc> --- and getting a lot of failures due to timeouts. Is there a way jtc> to increase the timeout value? Nevermind. I found that "set timeout X" at the end of site.exp does the trick. Unfortunately, it appears that the timeouts were caused by some sort of symbol handling bug which results in a null dereference (and thus a crash). --jtc -- J.T. Conklin RedBack Networks >From divx@euro.ru Tue Jan 09 14:41:00 2001 From: Eugene Kuznetsov To: gdb@sources.redhat.com Subject: Threading support with glibc 2.2 missing??? Date: Tue, 09 Jan 2001 14:41:00 -0000 Message-id: <361012815.20010109164310@euro.ru> X-SW-Source: 2001-01/msg00026.html Content-length: 991 Hello, I was using gdb 5.0 with glibc 2.1.2 ( ix86 Linux ) for a long time, and it worked pretty well for me. A few days ago I tried to upgrade my system to glibc 2.2, which I supposed to be stable. Immediately I discovered that I am no longer able to debug anything multithreaded at all - command 'info threads' is simply ignored, 'thread' shows information only about thread #0, and when program crashes with segfault, I am shown the position where it was in starting thread. I tried compiling sources of gdb from rawhide.redhat.com ( I suppose it was CVS snapshot from December 15th ). There things only gotten worse ( now even 'thread' does not show any meaningful information ). What am I doing wrong? Is there anything I can do to get debugging of multithreaded programs work again ( except reverting to glibc 2.1.2/gdb 5.0, of course )? Any help would be greatly appreciated. -- Best regards, Eugene mailto:divx@euro.ru