On Tue, Feb 08, 2000 at 12:26:45AM +1100, Andrew Cagney wrote: > With that in mind, I've tentatively planned: two weeks of > patch resolution; the cutting of the 5.0 branch (2000-02-21?); one week > of last minute checks; and then the 5.0 release (29/2 2000-02-29?). > (Everyone is free to roll on the floor laughing at this point :-) I think this is too aggressive. If we had the old source base, maybe it would be tenable, but the new repository has mixed the old GDB sources with a BFD that hasn't been sync'ed for something like six months. And there hasn't been a binutils release in over a year and a half--so the stability of binutils across a wide array of platforms has to be considered. Maybe it would be better to get some test results from a variety of common Unix platforms and decide based on how things look. NB cygwin support in binutils is noticably broken -- it will take at least a little work to get that resolved. On the other hand, I do agree that a release will go much more smoothly now that the repository is on sourceware. MHO, Jason From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Kevin Buettner Cc: gdb@sourceware.cygnus.com Subject: Re: Moving Linux-specific stuff out of i386-tdep.c Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C7AA6D.5465C647@cygnus.com> References: <200003082121.e28LLRu05681@delius.kettenis.local> <1000308222742.ZM8876@ocotillo.lan> X-SW-Source: 2000-q1/msg00643.html Content-length: 966 Kevin Buettner wrote: > > On Mar 8, 10:21pm, Mark Kettenis wrote: > > > Over time quite a lot of Linux-dependent stuff has been added to > > i386-tdep.c, and I think it's time to move that into its own file. > > But before I do that I'd like to get some clarification on some > > issue's. > > > > 1. Do we still care about the filename limits of older System V > > systems? i386-linux-nat.c is longer than 14 characters which is a > > no-no according to the GNU conding standards. > > I asked Andrew and Stan about this a short while ago. It seems that > the limits have been relaxed somewhat. (Stan proposed an 18 character > limit in our discussion.) Stan proposed it but I rejected it on the basis it was even more arbitrary than the existing 14 character limit. I beleve that ``Common Sense'' was the agreed lenth. Just need to remember to rename uw-thread.c to sco-unixware-thread.c ;-) The 8.3 uniqueness rule definitly still applies. Andrew From masahiro@ucom.lsi.nec.co.jp Sat Apr 01 00:00:00 2000 From: Masahiro Fukuda To: ogoh@cise.ufl.edu Cc: gdb@sourceware.cygnus.com Subject: Re: Error during installing GDB using Cygwin32. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000111145113B.masahiro@ucom.lsi.nec.co.jp> References: <001501bf5b23$b053fb20$8daae380@hsilab.cise.ufl.edu> X-SW-Source: 2000-q1/msg00017.html Content-length: 844 From: "Okehee Goh" Subject: Error during installing GDB using Cygwin32. Date: Mon, 10 Jan 2000 00:32:22 -0400 > Hi, > I'm now trying to install gdb-4.18 on the win98 using cygwin32. > But it gave out the following error message and faild to make gdb.exe. > > "gdb-4.18/readline/kill.c:611: undefined reference to 'OpenClipboard' > gdb-4.18/readline/kill.c:611: undefined reference to 'GetClipboardData' > gdb-4.18/readline/kill.c:611: undefined reference to 'CloseClipboard'" > > When I examined the related part of above error at kill.c, > these function was to support Cygwin32. Try the following or comment out these functions in kill.c. make WIN32LIBS=/cygnus/cygwin-b20/H-i586-cygwin32/i586-cygwin32/lib/libuser32.a -------- Fukuda, Masahiro Fingerprint20 = 23A4 6660 12FA ECFB 2518 27F2 48F1 B441 8138 F5A0 From blizzard@redhat.com Sat Apr 01 00:00:00 2000 From: Christopher Blizzard To: Mark Kettenis Cc: blizzard@mozilla.org, gdb@sourceware.cygnus.com, jakub@redhat.com, Jim Kingdon Subject: Re: problems with gdb Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A6E3F4.6551565F@redhat.com> References: <38A47E89.3F4674B3@mozilla.org> <200002121759.e1CHxMG02867@delius.kettenis.local> X-SW-Source: 2000-q1/msg00255.html Content-length: 6975 Mark Kettenis wrote: > > Date: Fri, 11 Feb 2000 16:26:33 -0500 > From: Chris Blizzard > > 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. :) > > No problem! > > May I ask some questions first? What version of GDB are you using? > What version of GCC are you using? > This is the gdb that is distributed with the Red Hat 6.2 Beta. I'm using this version of gcc: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) > 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. > > Let me first say that Mozilla seems to stretch things to the limit. > The huge number of shared libraries that you guys are using have > already uncovered several bugs in the dynamic linker and the Mozilla > developers have uncovered more than a few bugs in the LinuxThreads > library. That's mostly because you have gone where no one's gone > before :-) > Hey, we're trying. :) Someone pointed out to me that the problem didn't start happening until after I upgraded to 6.1 -> 6.2 beta. So, it could be any of the components on the system. > >From a quick glance at the output of `ps' on my system when loading a > program that uses about 10 shared libraries it seems that > the GDB memory usage is aproximately equal to the size of the shraed > libraries on disk. I guess the "factor 5" estimate, is referring to > the space used for debugging symbols as compared to the actual > code-size of the shared library. So it seems that your biggest > problem is the size of your shared libraries and the amount of > debugging information that's generated (which is basically > proportional to the amount of code in the libraries). I think that > using C++ is in a large way responsible for the `code bloat'. Maybe > an intelligent use of C++ features (check for compiler switches like > -fno-rtti and use them if appropriate) can reduce the size of the > resulting code. Also playing around with the options that control the > way debugging information is generated might help. > Here's how I'm compiling now: c++ -o nsLocalFileUnix.o -c -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wbad-function-cast -Wcast-align -Woverloaded-virtual -Wsynth -Wshadow -pedantic -Wno-long-long -pthread -g -DMOZILLA_CLIENT -include ../../config-defs.h -Wp,-MD,.deps/nsLocalFileUnix.pp -DOSTYPE=\"Linux2.2.15-2.5\" -DOJI -D_IMPL_NS_COM -D_IMPL_NS_BASE -D_BSD_SOURCE -I../../dist/include -I../../include -I/usr/X11R6/include -fPIC nsLocalFileUnix.cpp We're not compiling with optimization and we're reducing size as much as possible. > In principle the large amounts of debugging info shouldn't be a > problem. GDB can simply mmap the relevant sections, such that only > the debugging info that's really needed is actually pages in. I don't > know how the BFD library (the part of GDB that is responsible for > reading the sections containing debugging info) and the code that that > actually interprets this information implements these things. There > might be room for improvement there. Of course if all pages > containing debugging info are touched, you lose :-(. > > 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. > > It is a known problem that GDB has problems with the debugging output > generated by recent GCC compilers. Help in resolving those problems > would certainly be appreciated, and a (small) test case is really > essential if you want to get somebody else to look into it. > > Compiling without optimization might circumvent these problems. > > 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. > > I think that the way GDB looks up symbols is differs from the way > the dynamic linker does that. That means that overriding symbols in > shared libraries probably doesn't work properly. Since the primary > use of preloaded shared libraries is overriding symbols you're likely > to experience problems. I don't think this problem is easy to solve. > > Setting breakpoints in not-yet loaded shared libraries should not be > difficult to implement. Just make sure they start out as > `shlib_disabled' (see breakpoint.h) if the symbol cannot be found. It > is necessary to introduce a new command to do this (suggested name > `shlib-break' or `solib-break'). Reusing the guts of the ordinary > breakpoint setting command should be possible. > > 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. > > Probably caused by the strange way threads interact with signals on > Linux. It's very likely that the real bug is in the LinuxThreads > library and not in GDB. A lot of LinuxThreads problems have recently > been solved. You might want to try the latest glibc 2.1.3 > pre-release. Or have a little patience, glibc 2.1.3 is supposed to be > released real soon now. I think the Red Hat beta comes with a 2.1.3 pre release. --Chris -- ------------ Christopher Blizzard http://people.redhat.com/blizzard/ ------------ From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: David Williams Cc: William Gatliff , "gdb@sourceware.cygnus.com" Subject: Re: Breakpoints Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38715252.4AFCF918@cygnus.com> References: <01BF4D1C.4AD8ABC0.davidwilliams@ozemail.com.au> <3870B8E0.B4BB4034@haulpak.com> <38711A49.C239221D@ozemail.com.au> X-SW-Source: 2000-q1/msg00003.html Content-length: 697 David Williams wrote: > > I have seen gdb use breakpoints when steping at the source level. It mostly uses > multiple 's' packets but occasionally uses a break point. Of course when stepping > over a function (next) it always uses a breakpoint. No one has given me a > definitive answer on this, but from my experience so far it would seem that gdb > does not set multiple breakpoints when stepping (using either step or next). If > anyone has had a different experience I would love to hear from you. It's target dependant. Some architectures don't know how to single step and instead are forced to set multiple breakpoints. Of hand the old RS6000 (pre PowerPC) would be an example. Andrew From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon To: gdb@sourceware.cygnus.com Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <389ECBAF.66013B07@cygnus.com> <200002071626.RAA18391@landau.wins.uva.nl> X-SW-Source: 2000-q1/msg00125.html Content-length: 2004 > * Support for unloading of shared libraries. The current code-base > doesn't really support this. HJ Lu forwarded some patches that hack > around this, but I don't think they are acceptable. They introduce > two more (uneccessary) hooks. Personally I don't fixing this for > GDB 5.0 terribly important. There isn't that many code out there, that > explicitly unloads shared libs. As far as I know there is more out there than you might realize. A modern application like mozilla uses dlopen() a lot (feel free to flame about whether this tendency is a fad or really useful but that isn't the point). For example see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=5130 I'm hoping to find time to look at this. Whether or not it is me, I hope that we can get some victims ^W contributors working on finding a solution rather than merely talking about what was wrong with the patch which was sent to this list. But I wouldn't ask that this hold up GDB 2000. It could be a somewhat involved process to get a good solution. IMHO, a release is the time to stabilize what is already there, rather than to start hacking away to add new stuff. > I think having an "x86 linux native" port with working threads support > in GDB 5.0 is very important. Have you tried GDB from CVS in the last 6 months or so? I'm not aware of any known bugs and Red Hat Linux has been shipping with the code which is in CVS for a while (I can offer details if needed). > Another problem is that the official maintainer of "x86 linux > native" seems to be very busy lately. I don't blame Jim [Blandy] > for "having a life" Well, I'm likely to get/stay involved since I just told the Red Hat Linux people that I'd continue to build the packages for GDB. If you think maintainer bandwidth is what is holding up things like the long double one, feel free to see if there is anything I can do to help (although I'm not official the way JimB is, at least not yet). From grante@visi.com Sat Apr 01 00:00:00 2000 From: Grant Edwards To: gdb@sourceware.cygnus.com Subject: "print" to a file? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000303173101.A17076@visi.com> X-SW-Source: 2000-q1/msg00528.html Content-length: 227 I've been searching info pages and other documentation for a while, and still can't figure out how to redirect the output of a "print" command to a file or dump a section of memory to a file. -- Grant Edwards grante@visi.com From weech@primenet.com Sat Apr 01 00:00:00 2000 From: Brent Weech To: gdb@sourceware.cygnus.com, cygwin@sourceware.cygnus.com Subject: GDB error 87 under Cygwin Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <4.3.2.20000226214059.00b8f008@pop.primenet.com> X-SW-Source: 2000-q1/msg00426.html Content-length: 1728 Where in the world in the Errors.h file that enumerates the error codes coming from GDB?  In particular, I am interested in error 87, as shown below: BLACKBOX> gdb h-hcube                                                    GNU gdb 4.18 Copyright 1998 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 "i586-cygwin32"...(no debugging symbols found)... (gdb) r Starting program: //e/h-hcube.exe Error creating process //e/h-hcube.exe, (error 87) I'm sure the answer to this question is somewhere on the Cygnus and/or GDB mailing archive, but for the life of me I can't figure out how to get the wonderfully worthless ht://Dig search engine to accept phrase or boolean searches with any accuracy.  It has got to be one of the most frustrating search engine software packages I have ever used.  For example, try the following: On the Cygwin Project archive, a search for "error 87" set to match all terms or a boolean search for "error and 87" both give 5474 matches. On the same archive, a search for "error" gives (yes, I'm sure you can guess) the same 5474 matches! But on the same archive, a search for "error 193" set to match all terms only gives 21 hits. What gives?  A search though many of the "error 87" hits confirms that the string 87 is nowhere in the text or source of the html page. Someone tell me how to do a reliable phrase search of the mail archives. Brent Weech