From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: gdb@dontknow.org Cc: gdb@sourceware.cygnus.com Subject: Re: Linux threads support in GDB Date: Mon, 02 Oct 2000 05:57:00 -0000 Message-id: <200010021257.e92CvRm16644@debye.wins.uva.nl> References: <200009140024.e8E0OCK13917@mbox.wins.uva.nl> X-SW-Source: 2000-10/msg00001.html Date: Wed, 13 Sep 2000 18:25:21 -0600 (MDT) From: gdb@dontknow.org Appologies for the this late reply. Meanwhile, the particular failing assertions you were seeing should be gone. Ok, here is a test case that will reproduce the problem (to some extent anyways). I guess for some of my testing trying to reproduce the problem with something similiar I was using GDB 5.0, not the cvs version. However that version also has problems with the following code.) Normally when I run the real application I have SIGSTOP and SIGCONT set to nostop, which may be why it isn't seen until a breakpoint is used, whereas here it happens after the implicit SIGCONT breakpoint. Hmm. GDB heavily relies on SIGSTOP itself. There is no other way to stop threads in Linux :-(. Due to the nature of signals (particularly the fact that multiple signals might be merged into one), this rather hoplessly interferes with the SIGSTOPs you're using in your program. I really don't intend to fix this. Sorry. Mark PS Please keep CC'ing the GDB mailing list. These discussions could be useful for other people too. >From Peter.Schauer@regent.e-technik.tu-muenchen.de Mon Oct 02 10:04:00 2000 From: "Peter.Schauer" To: gdb@sourceware.cygnus.com Cc: ezannoni@cygnus.com Subject: Problem with 2000-05-05 elfread.c change Date: Mon, 02 Oct 2000 10:04:00 -0000 Message-id: <200010021704.TAA02459@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-10/msg00002.html Content-length: 2054 Problem with 2000-05-05 elfread.c change This change: 2000-05-05 Elena Zannoni * elfread.c (elf_symtab_read): The calculation of 'offset' must be done for each symbol, not just once. The index used must be the index of the section where 'sym' resides, not .text. causes subtle and difficult to track down problems with some gcc compiled C++ executables. These executables have a very large number of .gnu.linkonce sections when using native ld on Solaris (I have not yet tried GNU ld, but GDB should work with executables generated with native ld). As an example, testsuite/gdb.c++/virtfunc contains 95 sections, our large C++ application 2750 sections. The large number of sections causes an indexing beyond the bounds of the offsets array in the ANOFFSET macro, which does no bounds checking. So intermittent garbage is obtained for the offset value, causing symbols to obtain the wrong address. I hope that you have access to a GNU Solaris toolchain using native ld. You should then be able to verify the problem by applying the ANOFFSET bounds checking kludge below (can't use SECT_OFF_MAX, because not all users of ANOFFSET include gdb-stabs.h). Run the resulting GDB on testsuite/gdb.c++/virtfunc and watch it die... *** ./symtab.h.orig Fri Sep 15 21:27:33 2000 --- ./symtab.h Fri Sep 29 23:22:48 2000 *************** *** 831,837 **** #define ANOFFSET(secoff, whichone) \ ((whichone == -1) ? \ ! (internal_error ("Section index is uninitialized"), -1) : secoff->offsets[whichone]) /* The maximum possible size of a section_offsets table. */ --- 831,840 ---- #define ANOFFSET(secoff, whichone) \ ((whichone == -1) ? \ ! (internal_error ("Section index is uninitialized"), -1) : \ ! ((whichone >= 40) ? \ ! (internal_error ("Section index out of bounds"), -1) : \ ! secoff->offsets[whichone])) /* The maximum possible size of a section_offsets table. */ -- Peter Schauer pes@regent.e-technik.tu-muenchen.de >From gdb@dontknow.org Mon Oct 02 16:00:00 2000 From: gdb@dontknow.org To: Mark Kettenis Cc: gdb@sourceware.cygnus.com Subject: Re: Linux threads support in GDB Date: Mon, 02 Oct 2000 16:00:00 -0000 Message-id: References: <200010021257.e92CvRm16644@debye.wins.uva.nl> X-SW-Source: 2000-10/msg00003.html Content-length: 2178 On 02-Oct-00 Mark Kettenis wrote: > Date: Wed, 13 Sep 2000 18:25:21 -0600 (MDT) > From: gdb@dontknow.org > > Appologies for the this late reply. Meanwhile, the particular failing > assertions you were seeing should be gone. > > Ok, here is a test case that will reproduce the problem (to some > extent anyways). I guess for some of my testing trying to reproduce > the problem with something similiar I was using GDB 5.0, not the > cvs version. However that version also has problems with the > following code.) Normally when I run the real application I have > SIGSTOP and SIGCONT set to nostop, which may be why it isn't seen > until a breakpoint is used, whereas here it happens after the > implicit SIGCONT breakpoint. > > Hmm. GDB heavily relies on SIGSTOP itself. There is no other way to > stop threads in Linux :-(. Due to the nature of signals (particularly > the fact that multiple signals might be merged into one), this rather > hoplessly interferes with the SIGSTOPs you're using in your program. > I really don't intend to fix this. Sorry. And my application requires the occassional use of SIGSTOP for stopping threads (as you said, there is no other way to do it, at least not that I can find.) However I am not exactly sure what the cause of the problem is. Especially considering that a signal is sent to a single thread and not all threads (with the possible exceptions of the main thread or signals from the shell). This behavior is where Linux is different than standard PTHREADS (otherwise the use of SIGSTOP would be a bad thing for my application.) Another problem that I am seeing with the threading is that exiting threads are ending up defunct rather than going away while using GDB (correct behavior is seen w/o GDB). Is SIGCHLD is being handled correctly? IIRC that is the cause of that. > Mark > > PS Please keep CC'ing the GDB mailing list. These discussions could > be useful for other people too. Ok, I'll try to remember. I'm subscribed to the gdb-bug list but not the gdb list. Contrary to popular belief, UNIX is user friendly. It just happens to be selective about who it makes friends with.