Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release

[Jason Molenda <jsm@cygnus.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 17543 bytes --]

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 <ac131313@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
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 <masahiro@ucom.lsi.nec.co.jp>
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" <ogoh@cise.ufl.edu>
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 <blizzard@redhat.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: blizzard@mozilla.org, gdb@sourceware.cygnus.com, jakub@redhat.com, Jim Kingdon <kingdon@redhat.com>
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 <blizzard@mozilla.org>
> 
>    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 <ac131313@cygnus.com>
To: David Williams <davidwilliams@ozemail.com.au>
Cc: William Gatliff <gatliff@haulpak.com>, "gdb@sourceware.cygnus.com" <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 <kingdon@redhat.com>
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: <bog9tj5y3.fsf@rtl.cygnus.com>
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 <grante@visi.com>
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 <weech@primenet.com>
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