From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Blizzard To: gdb@sourceware.cygnus.com Subject: problems with gdb Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A47E89.3F4674B3@mozilla.org> X-SW-Source: 2000-q1/msg00232.html Hi, folks. I've been talking about some problems that I've been suffering through with gdb and mozilla which people on this mailing list may or may not be aware of. Jason Molenda suggested that I start flushing these out in the open to get some feedback on them. I'm interested in getting my hands dirty and try to get these problems fixed. I'm not a debugger hacker though so I might end up asking some silly questions. :) Here's the blurb, slightly edited for content. ...My problems are mostly related to how well gdb scales to handle large shared libraries and large numbers of shared libraries. At last count, there were 111 .so files in mozilla, the largest of which is about 27 meg with debugging symbols. If you don't use "set auto-solib-add 0" in your .gdbinit file, gdb will easily grow to over 200 meg in size when starting the debugger. Someone once did some estimates and it seems to use 5 times the size of a .so after loading a shared library to debug. A lot of times, gdb won't be able to load some of the larger .so files. It just hangs. A lot of times, trying to use "step" to step into a c++ method that happens to be part of the same class just skips as if you had used "next." That means that any time you want to step into a method you have to set a temporary breakpoint by name on the method and then allow the breakpoint to get you into that method. Doing that to step into a dozen or so classes gets a little tedious. This is hard to reproduce and I'm trying to build a test case. There are other much needed features, like not being able to preload a .so and setting a breakpoint in the library before it loads. Mozilla is entirely component based and this makes debugging very, very difficult. I usually break on _dl_open in glibc and wait until my library gets loaded before trying to set the breakpoint that I need. That gets pretty bad after 27 libraries are loaded. There are also various problems with threads. A lot of times gdb won't exit after the last thread exits because it keeps trying to kill a process which doesn't exist any more. We've got a deubugging FAQ that tries to show ways to work around deficencies in the deubugger: http://www.mozilla.org/unix/debugging-faq.html There are a lot of people who work at Netscape who would be using Linux as their primary platform if, and I'm quoting here, "using gdb wasn't like scratching your own eyes out." This is one of the reasons why Mozilla is so much slower on Linux than it is on windows. People waste so much time debugging on it that they just give up. --Chris -- ------------ Christopher Blizzard http://people.redhat.com/blizzard/ I'm not into working out. My philosophy: No pain, no pain. ------------ >From shebs@apple.com Sat Apr 01 00:00:00 2000 From: Stan Shebs To: "H . J . Lu" Cc: Andrew Cagney , Mark Kettenis , jtc@redback.com, gdb@sourceware.cygnus.com Subject: Re: A patch for gnu-regex Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C84793.8E138624@apple.com> References: <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com> <5mg0u2l3g0.fsf@jtc.redbacknetworks.com> <20000307162127.D485@lucon.org> <200003080044.e280iGB00429@delius.kettenis.local> <5m4saivyew.fsf@jtc.redbacknetworks.com> <38C82D34.31E36610"@cygnus.com> <20000309153922.A8624@lucon.org> X-SW-Source: 2000-q1/msg00666.html Content-length: 1864 "H . J . Lu" wrote: > > A GNU/Linux distributor is free to build a GDB that regexp from an > > installed glibc. Actually such a distributor is free to do what ever > > they like :-) > > Are you saying as far as gdb is concerned, you have no interests > whatsoever in glibc nor helping glibc developers and GNU/Linux > distributors? If it is true, that is too bad. Let's not get all tense here! There's a balance to be struck between being self-contained and depending on system stuff, and there's no single rule that applies in all cases. For instance, GDB includes libiberty, even though many of the functions are available on most systems by default, including Linux, but I don't seem to hear anybody complaining about that bit of redundancy. (Hmmm, why isn't regex in libiberty anyway??) In the case of GDB on Linux, part of our problem is that we have to support GDB on all versions of Linux, not just the latest kernel and library. So if there is *any* version of glibc with a problematic regex, say one from 4-5 years ago, we need to think hard about whether we're going to hose people running a Linux that is that old. GDB's rule has been to maximize compatibility with a whole range of OS versions, and now that Linux has sailed past all other OSes in number and variety of versions, it's really putting our infrastructure to the test. In this case, my inclination would be to rely on the glibc regex by default. GDB users don't tend to push the boundaries of regexps in their daily debugging activities, and if recent glibcs are good, then it's seems unlikely that we'll ever get any bug reports stemming from regex problems. So we'll be taking a bit of a chance, but with the configuration option, and if we communicate to the glibc folks that we're now always depending on their version to be correct, I think things will work out OK. Stan >From hjl@lucon.org Sat Apr 01 00:00:00 2000 From: "H . J . Lu" To: Mark Kettenis Cc: gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: A revised patch for dlclose Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000307170321.A884@lucon.org> References: <20000307120800.A27315@valinux.com> <200003080058.e280wga00453@delius.kettenis.local> X-SW-Source: 2000-q1/msg00579.html Content-length: 1258 On Wed, Mar 08, 2000 at 01:58:42AM +0100, Mark Kettenis wrote: > Date: Tue, 7 Mar 2000 12:08:00 -0800 > From: "H . J . Lu" > > Here is a revised patch for dlclose. If you take a look at the > dynamic linker in glibc 2.1 or above, you will find that it informs > gdb about loading/unloading a shared library via an internal debug > function, _dl_debug_state (). gdb already handles the loading in > handle_inferior_event () with BPSTAT_WHAT_CHECK_SHLIBS and > BPSTAT_WHAT_CHECK_SHLIBS_RESUME_FROM_HOOK. However, we need also > check the unloading event. solib_verify () will be called only when the > dynamic linker calls _dl_debug_state (). It shouldn't introduce any > overhead. I believe it is on the right track although it may be further > optimized. > > HJ, please stop wasting your time pushing this patch. The patch has > several bad points, that you cannot fix without considerable changes > to the way solib.c handles and caches the link map. I just pointed out gdb needed to check the unloaded DSOs when handling the BPSTAT_WHAT_CHECK_SHLIBS and BPSTAT_WHAT_CHECK_SHLIBS_RESUME_FROM_HOOK events. It is a serious bug to me and it should be fixed in 5.0. I don't care how it is fixed. H.J. >From muller@cerbere.u-strasbg.fr Sat Apr 01 00:00:00 2000 From: Pierre Muller To: Mark Kettenis Cc: gdb@sourceware.cygnus.com Subject: Pascal language support patch preparation Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003021347.OAA01051@cerbere.u-strasbg.fr> References: <200003021257.NAA00259@cerbere.u-strasbg.fr> X-SW-Source: 2000-q1/msg00500.html Content-length: 2092 At 14:21 02/03/00 +0100, you wrote: > Date: Thu, 02 Mar 2000 13:41:58 +0100 > From: Pierre Muller > > I want to format my PATCH for pascal extension before submitting it > so I read that I should use GNU indent with -gnu option ! > >Hi Pierre, I do hope that you'll break your patch up in some smaller >chunks. IMHO the fact that you sent it as a large chunk, was one of >the main reasons why it was ignored last fall. But adding a new language means at least : new files : p-lang.h p-lang.c p-valprint.c p-typeprint.c and p-exp.y plus the changes needed to make GDB know about pascal language ! This means a bunch of other changes of course ! > But I tried this on c-lang.h just to see > and the result is that the current header file does not conform to > indent output ! > >Looks like you're using a different `indent' than was used on the GDB >sources. I think, this shows that defining the GDB coding standards >in terms of the output of `indent' is not really workable. I've also >noticed that `indent' sometime really messes up the output, because it >gets confused by certain constructs. indent --version gives "GNU indent 2.2.5" is that not the current version ?? > So my question is simply should I run indent on my files > or should I send them without ! > >I'd say that avoiding gratuitous reformatting is more important than >running your changes through `indent'. Thus, make sure that your >patches only contains changes for code you really changed, and that >these changes correspond to the GNU coding standards. One of the main problem is that my patches are primarily files c-*.* first copied to p-*.* then adapted to reflect pascal instead of C, but of course this copy was primarily done on v4.17 ! I change after so that it compiled with v4.18, but all the changes made in c-*.* since then are not in my pascal files. Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99 >From jlarmour@redhat.co.uk Sat Apr 01 00:00:00 2000 From: Jonathan Larmour To: gdb@sourceware.cygnus.com Subject: copyright banner and reporting bugs Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38CFF922.6BA6928E@redhat.co.uk> X-SW-Source: 2000-q1/msg00712.html Content-length: 570 I just noticed two minor things: surely the copyright banner when GDB starts should be something more recent than 1998 even now - i.e. it shouldn't need to wait for the release. Also on http://sourceware.cygnus.com/gdb it isn't at all clear how users report bugs. This is worthy of a section in its own right surely! Just an appropriate regurgitation of the info file node from gdb.texinfo would be enough. Jifl -- Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762 "Plan to be spontaneous tomorrow." || These opinions are all my own fault >From toddpw@windriver.com Sat Apr 01 00:00:00 2000 From: Todd Whitesel To: gdb@sourceware.cygnus.com (GDB Developers) Subject: Readline and -DMINIMAL Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003281230.EAA15638@alabama.wrs.com> X-SW-Source: 2000-q1/msg00823.html Content-length: 673 I have just discovered to my horror that the upgrade to Readline 2.2 in GDB 4.18 has completely eradicated support for the MINIMAL #define, and provides no alternative -- it simply assumes BSD style ttys and falls over dead if those aren't supported. Does anyone know the story on this one? Is there a stub library that is used for Cygwin and DJGPP ? I noticed a specific hack for cygwin that simply assumes libtermcap.a, I suppose this is a B20 invention. I really do not want to hack all the #ifdef MINIMAL stuff back in, but since I build direct on windows I need to shut up all the code that tries to use sgtty or termios. -- Todd Whitesel toddpw @ windriver.com >From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: jtc@redback.com Cc: eliz@is.elta.co.il, gdb@sourceware.cygnus.com Subject: Re: Running the inferior from breakpoint commands Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003162229.e2GMTda00304@delius.kettenis.local> References: <200003120759.CAA24402@indy.delorie.com> <5mem9ad1vw.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00724.html Content-length: 584 From: jtc@redback.com (J.T. Conklin) Eli> The DJGPP version seems to behave like HPPA (I'm not sure whether this Eli> is a compliment, and if so, to which of the two systems ;-). However, Eli> I stepped through the code that is involved, and I don't see anything Eli> DJGPP-specific there. It's been a while, but if I remember correctly, this test failed when I ran the testsuite on NetBSD/i386. It appeared that someone changed the testsuite to match HPUX's behavior instead of letting the test fail. The test fails on the Hurd and Linux/i386 too. Mark >From akale@veritas.com Sat Apr 01 00:00:00 2000 From: "Amit S. Kale" To: Todd Whitesel , kingdon@redhat.com (Jim Kingdon) Cc: akale@veritas.com, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Regression caused by elfread.c patch Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <00021514224700.31608@fermat.vxindia.veritas.com> References: <200002150800.AAA07477@alabama.wrs.com> X-SW-Source: 2000-q1/msg00291.html Content-length: 2745 Hi, On Tue, 15 Feb 2000, Jim Kingdon wrote: > > That was because Jim didn't checkin my patch correctly. > > He has fixed it now. > > No, this is a different problem. Apolgies to Jim, because the problem was not his fault as said by me. > I don't see how your patch could work at all - sym->section->index is > a very different number than a SECT_OFF_* code. The SECT_OFF_* code > (which gets fed to ANOFFSET) isn't computed until later in the > function (via the call to record_minimal_symbol_and_info). The patch I sent is working in some configurations. I have been using it for debugging linux kernel. This patch was needed to load module object files using 'add-symbol-file' after loading kernel object file using 'symbol-file'. I guess gdb first prepares text, data, bss segments and following code bfd/section.c:bfd_make_section_anyway(): newsect->index = abfd->section_count++; indicates that section->index contains SECT_OFF_* codes when segments are loaded. This may not have been designed this way, but it seems to be that way. Using sym->section->index is not right for segments that are not text or data segments. Using sym->section->index should be all right for data segments. I suggest following patch. I have verified that the vfprintf problem reported by Mark does not appear with this patch. I haven't tested it with test suite. --- elfread.c Tue Feb 15 13:54:52 2000 +++ ../../../utils/src/gdb/elfread.c Tue Feb 15 10:56:30 2000 @@ -293,14 +293,11 @@ elf_symtab_read (objfile, dynamic) if (number_of_symbols < 0) error ("Can't read symbols from %s: %s", bfd_get_filename (objfile->obfd), bfd_errmsg (bfd_get_error ())); + /* FIXME: Should use section specific offset, not SECT_OFF_TEXT. */ + offset = ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT); for (i = 0; i < number_of_symbols; i++) { sym = symbol_table[i]; - if (sym->section->flags & SEC_DATA) { - offset = ANOFFSET (objfile->section_offsets, sym->section->index); - } else { - offset = ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT); - } if (sym->name == NULL || *sym->name == '\0') { /* Skip names that don't exist (shouldn't happen), or names On Tue, 15 Feb 2000, Todd Whitesel wrote: > [snip] > However, so few configurations (read: vxWorks and ??) actually use different > offsets for, say, SECT_OFF_TEXT and SECT_OFF_DATA, that no one notices the > problems with it. (We read relocatable .o files too, which is also rare.) It won'd be rare when gdb will be used by more people to debug linux kernel modules. > [snip] -- Amit Kale Veritas Software ( http://www.veritas.com ) >From hjl@valinux.com Sat Apr 01 00:00:00 2000 From: "H . J . Lu" To: GDB Subject: Today's gdb broken on Linux/ia32 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000307141732.A21740@valinux.com> X-SW-Source: 2000-q1/msg00567.html Content-length: 255 With today's gdb from CVS, I got: # /work/build/gnu/bin/gdb.orig/gdb/gdb ex1 (gdb) r Starting program: /work/build/gnu/bin/glibc-2.1.old/linuxthreads/ex1 [New Thread 1024 (runnable)] ex1 is from linuxthreads in glibc 2.1.3. -- H.J. Lu (hjl@gnu.org) >From qqi@world.std.com Sat Apr 01 00:00:00 2000 From: Quality Quorum To: gdb@sourceware.cygnus.com Subject: Z-protocol errors and limts Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: X-SW-Source: 2000-q1/msg00056.html Content-length: 529 Hi, I have a few questions related to Z-protocol on implmentation on the stub side: 1. How many soft break point has to be supported ? 2. How stub tells gdb that it run out of soft break points ? 3. If stub supports soft break points but does not support hw (or some of hw break points), how it tells gdb about it ? I suppose that all thesecurrenly are errors and it is a responsibility of the gdb to not blow out any limits. However, I did not see any specification limiting number of soft breaks. Thanks, Aleksey