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

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

[Andrew Cagney]

"H . J . Lu" wrote:
> 
> On Mon, Feb 07, 2000 at 12:46:56PM -0500, Jim Kingdon wrote:
> >
> > I mean, if we want to delay GDB 5.0 until after things have settled
> > down a bit, that might be OK, but I guess speaking for myself I'd be
> > happy to get 5.0 out quickly and then get started on 5.1.
> 
> If we do so, we have to explain it to those contributors and we
> have to fix it in 5.1 in a month or so, not 6 months or a year.
> Should we set a deadline for each bug where a working, but not
> ideal, patch exists? If we cannot find a better one before certain
> date, we will use the existing one.

If you count the months, July is less than 6 months away.  I've already
indicated that 5.1 is expected in that time frame.

With that said, I would consider a one month gap between 5.0 and 5.1 to
be unrealistic. I'd also consider it un-reasonable to mandate the
acceptance of patches just because a reasonable solution isn't
available.  It's important to remember that the person submitting the
quick-hack isn't the one that is going to be responsible for the long
term maintenance that that hack creates.

Any way, once 5.0 has been released, patches to any deadly serious bugs
(read core-dumps) are likely to be appended to the end of the 5.0 CVS
branch.  Someone wanting a 5.0 with fixes can then use a mechanism like
CVS update to obtain the fixes.  There is a very very small chance that
a 5.0.1 is needed (previous experience suggests that this is unlikely)
and far greater benefit can be had by ensuring the next major release is
made in a timely fashon.

	enjoy,
		Andrew
From qqi@world.std.com Sat Apr 01 00:00:00 2000
From: Quality Quorum <qqi@world.std.com>
To: hollerer@gmx.net
Cc: gdb@sourceware.cygnus.com
Subject: Re: remote debugging via rs332c - output lost
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <Pine.SGI.3.95.1000112145321.6887B-100000@world.std.com>
References: <387CD579.C2EFEEBF@gmx.net>
X-SW-Source: 2000-q1/msg00024.html
Content-length: 742

On Wed, 12 Jan 2000 hollerer@gmx.net wrote:

> hi,
> 
> i am remote debugging programs which makes output
> like
>   printf("xxx called\r\n");
> 
> it outputs the string on it's serial interface.
> the same interface as used for gdb.
> debugging generally works. but the host gdb does not
> show the sent string.
> what must i do that the host gdb shows output of the
> remote program?

wrap it into 'O' message.
> 
> thx
> franz hollerer
> 
> host: linux suse 6.1 (kernel 2.2.7 i586)
> target: m68332 microcontroller board
> 
> host gcc: egcs-2.91.66
> gcc for cross compilation: m68k-aout-gcc version 2.95.2
> gdb for remote debugging: m68k-aout-gdb version 4.18
> 
> -- 
> Austria
> Usually we don't have kangaroos.
> 

Thanks,

Aleksey

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

[Patrick J. LoPresti]

Andrew Cagney <ac131313@cygnus.com> writes:

> With that said, I would consider a one month gap between 5.0 and 5.1 to
> be unrealistic. I'd also consider it un-reasonable to mandate the
> acceptance of patches just because a reasonable solution isn't
> available.

I think it depends on the situation.  At this point, stock GDB has
been broken on Linux/x86 for several *years*.

The problem with debugging across dlopen()/dlclose()/dlopen() sounds
complicated.  It is also fairly obscure.  However, being unable to use
breakpoints in *any shared library at all* is not obscure.  It makes
stock GDB extremely painful for a lot of uses.  If GDB 5.0 is released
with the same problem, I suspect the word among Linux developers will
be the same as it has been for the last few years: "Stock GDB is
broken; don't use it."

The SamL/H.J. patches fix the problem, as far as we can tell here.
And those patches are not very large.  Is it really so hard to put
them in and fix the problem the Right Way later?  The argument "we
can't accept every hack" is pretty weak.  You are not being asked to
accept every hack, you are being asked to accept a single hack which
addresses a very serious problem on a major platform.

Just $0.02 from a developer who is tired of manually patching
prereleases...

 - Pat
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gdb@sourceware.cygnus.com
Subject: COERCE_FLOAT_TO_DOUBLE
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003050836.DAA10166@indy.delorie.com>
X-SW-Source: 2000-q1/msg00543.html
Content-length: 428

The comments about COERCE_FLOAT_TO_DOUBLE in valops.c seem to suggest
that every modern architecture should define it to
standard_coerce_float_to_double.  I was about to add that definition
to tm-go32.h when I noticed that none of the other i386 targets,
including linux native, does that--they all use the default
definition.

Shouldn't most/all i386 targets, at least those which use GCC, use
standard_coerce_float_to_double?
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Love <lha@stacken.kth.se>
Cc: gdb@sourceware.cygnus.com, assar@sics.se
Subject: Re: backtrace from random $fp $pc
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A4F543.58AF8D8E@cygnus.com>
References: <amvh5xpigc.fsf@hummel.e.kth.se>
X-SW-Source: 2000-q1/msg00238.html
Content-length: 2647

Love wrote:
> 
> In a project I'm writing on we have a custom thread package. It
> context-switches on select and do stack mangling when.
> 
> Now there is to way to do backtrace:ing on diffrent threads.
> 
> I have a patch (on 4.18) that enable us to do that
> < http://www.stacken.kth.se/projekt/arla/gdb-4.18-backfrom.diff > by
> choosning the right $fp and $sp. Se below for example (the exemple uses
> wrong $pc). As you see I use a sequence to find fp/pc.

The thing to do is study how one of the *thread* modules have been
implemented.  If you can teach GDB how to find the per thread
information then it can automatically handle the threads.

> Now that question is, how should thread support really work for random
> thread-packages ? We have the idea that the thread package would provide a
> magic variable to a function that gdb sets and the thead package call each
> time it does a thread-releated operation that gdb needs to know.

At present, GDB is largely passive.  It lets the target run.  When the
target stops GDB is told, among other things, ``hey this is a new
thread''.  GDB then typically lets the target run again.
(The thread experts can ROTFL at this description :-)

> A many related question: What is tfind, since that seam to be releated to
> backtrace:ing (but on remote targets ?) would that be possible to use for
> the same things that my patch does ?

Without reading the manual/source, I don't know.

For the backtrace command, in theory, it is possible to set ``$fp'' and
as a side effect change the stack that GDB is displaying.  ($fp is not
what the VAX hackers might think - it's a badly named gdb internal
variable that provides a handle onto the frame.  It may or may not
correspond to a real register).

	enjoy,
		Andrew

> 
> Love
> 
> (gdb) lwp_ps
> Runnable[0]
>  name: IO MANAGER
>   eventlist:
>   fp: 0x806aac4
>   pc: 0x806aac4
>  name: producer
>   eventlist: 8048b00
>   fp: 0x8083b40
>   pc: 0x8083b40
> Runnable[1]
> [...]
> (gdb) help backfrom
> Print backtrace of FRAMEPOINTER and PROGRAMCOUNTER.
> 
> (gdb) backfrom 0x8083b40 0x8083b40
> #0  0x8083b40 in ?? ()
> #1  0x8049e2f in LWP_MwaitProcess (wcount=1, evlist=0x8083b70)
>     at /afs/e.kth.se/home/staff/lha/src/cvs/arla-foo/lwp/lwp.c:567
> #2  0x8049eaf in LWP_WaitProcess (event=0x8048b00)
>     at /afs/e.kth.se/home/staff/lha/src/cvs/arla-foo/lwp/lwp.c:585
> #3  0x8048b12 in Producer (foo=0x0)
>     at /afs/e.kth.se/home/staff/lha/src/cvs/arla-foo/lwp/testlwp.c:76
> #4  0x804a00c in Create_Process_Part2 ()
>     at /afs/e.kth.se/home/staff/lha/src/cvs/arla-foo/lwp/lwp.c:629
> #5  0xfffefdfc in ?? ()
> #6  0x8051980 in ?? ()
From blizzard@mozilla.org Sat Apr 01 00:00:00 2000
From: Christopher Blizzard <blizzard@mozilla.org>
To: gdb@sourceware.cygnus.com
Subject: problems loading shared libraries - with attached test case
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DFD84E.9F330EC1@mozilla.org>
X-SW-Source: 2000-q1/msg00820.html
Content-type: multipart/mixed; boundary="----------=_1583534245-23286-8"

This is a multi-part message in MIME format...

------------=_1583534245-23286-8
Content-length: 4225

Hi, I'm having problems loading shared libraries.  This is with a build
of gdb out of cvs that I pulled and built on March 27th and has been
there for at least a week.  I haven't gone back further than that.  This
is with the gcc that is shipping with Red Hat 6.2:

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)

I'm using "set auto-solib-add 0" after main has been called.  If I use
"shar" to load a shared library manually once I can't use it again to
load another shared library later.  Please see the attached log for an
example of how to reproduce the problem.

--Chris

GNU gdb 20000204
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 "i686-pc-linux-gnu"...
(gdb) break main
Breakpoint 1 at 0x8048576: file main.c, line 5.
(gdb) r
Starting program: /home/blizzard/src/gdb_test/main 

Breakpoint 1, main (argc=1, argv=0xbffff9c4) at main.c:5
5         void *handle0 = dlopen("./libdummy0.so", RTLD_LAZY);
(gdb) set auto-solib-add 0
(gdb) n
6         void *handle1 = dlopen("./libdummy1.so", RTLD_LAZY);
(gdb) n
7         void *handle2 = dlopen("./libdummy2.so", RTLD_LAZY);
(gdb) n
8         void *handle3 = dlopen("./libdummy3.so", RTLD_LAZY);
(gdb) n
9         printf("Hi.\n");
(gdb) shar dummy0
Reading symbols from /home/blizzard/src/gdb_test/./libdummy0.so...done.
Loaded symbols for /home/blizzard/src/gdb_test/./libdummy0.so
(gdb) shar dummy1
(gdb) info shar
From        To          Syms Read   Shared Object Library
0x4001a000  0x4001d08c  Yes         /lib/libdl.so.2
0x4001e000  0x4005ff90  Yes         /usr/lib/libstdc++-libc6.1-1.so.2
0x40060000  0x4007c9d8  Yes         /lib/libm.so.6
0x4007d000  0x4017185c  Yes         /lib/libc.so.6
0x40000000  0x40013ed0  Yes         /lib/ld-linux.so.2
0x40015000  0x40016cdc  Yes        
/home/blizzard/src/gdb_test/./libdummy0.so
0x40017000  0x40018cdc  No         
/home/blizzard/src/gdb_test/./libdummy1.so
0x40173000  0x40174cdc  No         
/home/blizzard/src/gdb_test/./libdummy2.so
0x40175000  0x40176cdc  No         
/home/blizzard/src/gdb_test/./libdummy3.so
(gdb) shar dummy3
(gdb) shar /home/blizzard/src/gdb_test/./libdummy2.so
(gdb) info shar
From        To          Syms Read   Shared Object Library
0x4001a000  0x4001d08c  Yes         /lib/libdl.so.2
0x4001e000  0x4005ff90  Yes         /usr/lib/libstdc++-libc6.1-1.so.2
0x40060000  0x4007c9d8  Yes         /lib/libm.so.6
0x4007d000  0x4017185c  Yes         /lib/libc.so.6
0x40000000  0x40013ed0  Yes         /lib/ld-linux.so.2
0x40015000  0x40016cdc  Yes        
/home/blizzard/src/gdb_test/./libdummy0.so
0x40017000  0x40018cdc  No         
/home/blizzard/src/gdb_test/./libdummy1.so
0x40173000  0x40174cdc  No         
/home/blizzard/src/gdb_test/./libdummy2.so
0x40175000  0x40176cdc  No         
/home/blizzard/src/gdb_test/./libdummy3.so
(gdb) 


-- 
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
I bet a funny thing about driving a car off a cliff is, while
you're in midair, you still hit those brakes! Hey, better try
the emergency brake!
------------
CFLAGS = -g

SHLIBS = libdummy0.so libdummy1.so libdummy2.so libdummy3.so
TARGET = main

all: $(SHLIBS) $(TARGET)

main: main.c
	g++ $(CFLAGS) -o main main.c -ldl

libdummy0.cpp: gen_files.pl
	./gen_files.pl dummy0 > libdummy0.cpp

libdummy0.so: libdummy0.cpp
	g++ $(CFLAGS) -o libdummy0.so -shared -fPIC libdummy0.cpp

libdummy1.cpp: gen_files.pl
	./gen_files.pl dummy1 > libdummy1.cpp

libdummy1.so: libdummy1.cpp
	g++ $(CFLAGS) -o libdummy1.so -shared -fPIC libdummy1.cpp

libdummy2.cpp: gen_files.pl
	./gen_files.pl dummy2 > libdummy2.cpp

libdummy2.so: libdummy2.cpp
	g++ $(CFLAGS) -o libdummy2.so -shared -fPIC libdummy2.cpp

libdummy3.cpp: gen_files.pl
	./gen_files.pl dummy3 > libdummy3.cpp

libdummy3.so: libdummy3.cpp
	g++ $(CFLAGS) -o libdummy3.so -shared -fPIC libdummy3.cpp

clean:
	rm -f libdummy*.cpp *.so *.o *~ main

------------=_1583534245-23286-8
Content-Type: text/x-perl; charset=us-ascii; name="gen_files.pl"
Content-Disposition: inline; filename="gen_files.pl"
Content-Transfer-Encoding: base64
Content-Length: 1627

IyEvdXNyL2Jpbi9wZXJsCgokbnVtID0gMTA7CgokcHJlZml4ID0gJEFSR1Zb
MF07CgppZiAoISRwcmVmaXgpIHsKICBkaWUoInVzYWdlOiBnZW5fZmlsZXMu
cGwgPHByZWZpeD5cbiIpOwp9CgpwcmludF9jbGFzc19kZWNsKCk7CnByaW50
X2NsYXNzX3VzZSgpOwojcHJpbnRfbWFpbl9zdGFydCgpOwojcHJpbnRfY2xh
c3NfdXNlKCk7CiNwcmludF9tYWluX2VuZCgpOwoKc3ViIHByaW50X2NsYXNz
X2RlY2wgewogIGZvciAoJGkgPSAwOyAkaSA8ICRudW07ICRpKyspIHsKICAg
IHByaW50ICgiY2xhc3MgZHVtbXlfIiAuICRpIC4gIl9rbGFzcyB7IHB1Ymxp
YzogaW50IGk7XG4iKTsKICAgIG15ICRqOwogICAgZm9yICgkaiA9ICRpIC0g
MTsgJGogPiAwOyAkai0tKSB7CiAgICAgIHByaW50ICgiZHVtbXlfIiAuICRq
IC4gIl9rbGFzcyBtZW1iZXJfIiAuICRqIC4gIjtcbiIpOwogICAgfQogICAg
cHJpbnQgKCJ9O1xuIik7CiAgfQp9CgpzdWIgcHJpbnRfY2xhc3NfdXNlIHsg
IAogIGZvciAoJGkgPSAwOyAkaSA8ICRudW07ICRpKyspIHsKICAgIHByaW50
ICgiJHByZWZpeF8iIC4gJGkgLiAiX2tsYXNzICpmb29fIiAuICRpIC4gIjtc
biIpOwogIH0KCiAgZm9yICgkaSA9IDA7ICRpIDwgJG51bTsgJGkrKykgewog
ICAgcHJpbnQgKCJmb29fIiAuICRpIC4gIiA9IG5ldyAiIC4gIiRwcmVmaXhf
IiAuICRpIC4gIl9rbGFzcygpO1xuIik7CiAgfQoKICBmb3IgKCRpID0gMDsg
JGkgPCAkbnVtOyAkaSsrKSB7CiAgICBwcmludCAoImZvb18iIC4gJGkgLiAi
LT5pID0gMjM7XG4iKTsKICB9Cn0KCnN1YiBwcmludF9jbGFzc191c2Ugewog
IGZvciAoJGkgPSAwOyAkaSA8ICRudW07ICRpKyspIHsKICAgIHByaW50ICgi
dm9pZCAiIC4gJHByZWZpeCAuICJfZnVuY18iIC4gJGkgLiAiKHZvaWQpIHsg
XG4iKTsKICAgIG15ICRqOwogICAgZm9yICgkaiA9IDA7ICRqIDwgJGk7ICRq
KyspIHsKICAgICAgcHJpbnQgKCJkdW1teV8iIC4gJGogLiAiX2tsYXNzIGJh
cl8iIC4gJGogLiAiO1xuIik7CiAgICB9CiAgICBwcmludCAoIn1cbiIpOwog
IH0KfQoKc3ViIHByaW50X21haW5fc3RhcnQgewogIHByaW50ICgiaW50IG1h
aW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KVxuIik7CiAgcHJpbnQgKCJ7XG4i
KTsKfQoKc3ViIHByaW50X21haW5fZW5kIHsKICBwcmludCAoInJldHVybiAw
O1xuIik7CiAgcHJpbnQgKCJ9XG4iKTsKfSAgCg==

------------=_1583534245-23286-8--
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Grant Edwards <grante@visi.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: printing array element broken?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38AA5296.E4C28331@cygnus.com>
References: <20000202102302.A29253@visi.com>
X-SW-Source: 2000-q1/msg00307.html
Content-length: 1280

Grant Edwards wrote:
> 
> I've an array of 4 structures named txFrameDescrArray.  When I
> print the entire array, everything is fine:
> 
> (gdb) print/x txFrameDescrArray
> $2 = {{FrameDataPtr = 0x100e10, Reserved = 0x14, StatusAndFrameLength = 0x40800094, NextFD = 0x105610},
>       {FrameDataPtr = 0x101400, Reserved = 0x14, StatusAndFrameLength = 0x40800094, NextFD = 0x105620},
>       {FrameDataPtr = 0x1019f0, Reserved = 0x14, StatusAndFrameLength = 0x40800094, NextFD = 0x105630},
>       {FrameDataPtr = 0x101fe0, Reserved = 0x0, StatusAndFrameLength = 0x0, NextFD = 0x105600}}
> 
> However, asking gdb to print an individual element results in garbage:
> 
> (gdb) print/x txFrameDescrArray[0]
> $3 = {FrameDataPtr = 0xfcfaa0ba, Reserved = 0xb8ff0003, StatusAndFrameLength = 0xbaeeffa2, NextFD = 0xb8ee70}
> 
> (gdb) print/x txFrameDescrArray[1]
> $5 = {FrameDataPtr = 0xfcfaa0ba, Reserved = 0xb8ff0003, StatusAndFrameLength = 0xbaeeffa2, NextFD = 0xb8ee70}
> 
> What am I doing wrong?

I guess you've compared:

	(gdb) print txFrameDescrArray
with	(gdb) print txFrameDescrArray[0]

and checked that that works ok.

Looking at your output, I suspect that yes, you've found a bug. 
Interested in extending the testsuite to test for this?  Or trying for a
patch?

	Andrew
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: GDB <gdb@sourceware.cygnus.com>
Subject: [hercules@lokigames.com: solib patch for gdb 4.17.0.14]
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000204124020.C1647@lucon.org>
X-SW-Source: 2000-q1/msg00105.html
Content-length: 2996

----- Forwarded message from Sam Lantinga <hercules@lokigames.com> -----

Delivered-To: hjl@lucon.org
Date: Mon, 31 Jan 2000 17:00:17 -0800
From: Sam Lantinga <hercules@lokigames.com>
Organization: Loki Entertainment Software
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
To: hjl@lucon.org
Cc: coders@lokigames.com, Sam Lantinga <hercules@lokigames.com>
Subject: solib patch for gdb 4.17.0.14


This patch fixes the shared library problem I mailed you about earlier.
This affects any code which dynamically unloads shared objects.  Games
are notorious for this. :)

See ya!
-- 
	-Sam Lantinga, Lead Programmer, Loki Entertainment Software
diff -ruN gdb-4.17/gdb/infrun.c gdb-4.17.new/gdb/infrun.c
--- gdb-4.17/gdb/infrun.c	Mon Jan 31 16:47:48 2000
+++ gdb-4.17.new/gdb/infrun.c	Mon Jan 31 16:39:20 2000
@@ -1192,6 +1192,9 @@
                   CHECK_SOLIB_CONSISTENCY();
 #endif
 		  SOLIB_ADD (NULL, 0, NULL);
+#ifdef UNLOAD_UNUSED_SOLIB
+                  UNLOAD_UNUSED_SOLIB();
+#endif
 	          target_terminal_inferior ();
 		}
 
diff -ruN gdb-4.17/gdb/solib.c gdb-4.17.new/gdb/solib.c
--- gdb-4.17/gdb/solib.c	Mon Jan 31 16:47:48 2000
+++ gdb-4.17.new/gdb/solib.c	Mon Jan 31 16:46:31 2000
@@ -918,6 +918,58 @@
 
 /*
 
+GLOBAL FUNCTION
+
+	unload_unused_solib -- dump symbols from unloaded shared objects
+
+SYNOPSIS
+
+	void unload_unused_solib (void)
+
+DESCRIPTION
+
+	This module is called whenever we hit a dynamic linker breakpoint
+	and allows us to unload objects which are no longer valid in the
+	in the inferior.
+
+AUTHOR
+	Sam Lantinga <hercules@lokigames.com>
+ */
+
+void
+unload_unused_solib (void)
+{
+
+#ifdef SVR4_SHARED_LIBS
+
+    struct objfile *current;
+
+    for ( current=symfile_objfile; current; current=current->next ) {
+        struct so_list *so;
+        char *bfd_filename;
+        for ( so=so_list_head; so; so=so->next ) {
+            if (so->abfd) {
+                bfd_filename = bfd_get_filename (so->abfd);
+                if ( bfd_filename ) {
+                    if ( strcmp(bfd_filename, current->name) == 0 ) {
+                        break;
+                    }
+                }
+            }
+        }
+        if ( (current != symfile_objfile) && (so == NULL) ) {
+/*printf("Freeing objfile: %s\n", current->name);*/
+            free_objfile(current);
+            break;
+        }
+    }
+
+#endif	/* SVR4_SHARED_LIBS */
+
+}
+
+/*
+
 LOCAL FUNCTION
 
 	find_solib -- step through list of shared objects
diff -ruN gdb-4.17/gdb/solib.h gdb-4.17.new/gdb/solib.h
--- gdb-4.17/gdb/solib.h	Mon Jan 31 16:47:48 2000
+++ gdb-4.17.new/gdb/solib.h	Mon Jan 31 16:40:14 2000
@@ -59,6 +59,10 @@
 
 #define CHECK_SOLIB_CONSISTENCY()	check_solib_consistency()
 
+/* Brute force check of library consistency */
+
+#define UNLOAD_UNUSED_SOLIB()		unload_unused_solib()
+
 /* If ADDR lies in a shared library, return its name.  */
 
 #define PC_SOLIB(addr)	solib_address (addr)


----- End forwarded message -----
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: kettenis@wins.uva.nl
Cc: 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: <200002072152.QAA06843@devserv.devel.redhat.com>
References: <389ECBAF.66013B07@cygnus.com> <200002071626.RAA18391@landau.wins.uva.nl> <bog9tj5y3.fsf@rtl.cygnus.com> <200002072132.WAA08489@soliton.wins.uva.nl>
X-SW-Source: 2000-q1/msg00137.html
Content-length: 1061

> And I hope that the patches I sent in the last few months "prove" this
> commitment.

Sending in patches is a great way to show commitment, yes.  Care to
list the patches which have been submitted but not checked in?  URLs
to sourceware.cygnus.com mail archives are sufficient, I'm not asking
for updating or new analysis unless perhaps if you know the old
submission is wrong.  You can see my own list (for patches I have
submitted) at http://people.redhat.com/kingdon/

At the risk of making an inflammatory and/or irrelevant analogy, I
think of it a little bit like TCP/IP.  In TCP, a sender needs to
retransmit if packets are dropped by IP.  Furthermore, in case of
congestion random-drop generally works better than queueing.

> A speedup in evaluation and/or integration of patches would certainly
> be welcome.  There have been suggestions like "write-after-approval"
> access for more people.

As far as I know this is underway (unless of course if everyone is
assuming someone else is taking care of making it happen).  Feel free
to keep bugging us.
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: ac131313@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: So who maintains the web pages?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002200454.XAA28897@devserv.devel.redhat.com>
References: <38A60492.2BB9E437@cygnus.com> <bu2jdc2mp.fsf@rtl.cygnus.com> <38ABB2C9.4102933B@cygnus.com>
X-SW-Source: 2000-q1/msg00350.html
Content-length: 262

> FYI, I'm a web section to the maintainers file and you're it!

I'm not sure how to parse that sentence but let me know if you are
asking me to send in suggested changes to MAINTAINERS or anything like
that (there isn't anything there yet about the web pages).
From aoliva@cygnus.com Sat Apr 01 00:00:00 2000
From: Alexandre Oliva <aoliva@cygnus.com>
To: binutils@sourceware.cygnus.com, gdb@sourceware.cygnus.com, newlib@sourceware.cygnus.com
Subject: `make check' with --enable-shared
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <ority3q10w.fsf@zecarneiro.lsd.ic.unicamp.br>
X-SW-Source: 2000-q1/msg00845.html
Content-length: 487

When the srcware tree is configured with --enable-shared, the `expect'
program won't run properly.  Jim Wilson found out gdb has a local hack
to set LD_LIBRARY_PATH, but, AFAIK, no other project has been hacked
similarly.

Here's a simple patch that renders that gdb hack obsolete, and
arranges for all packages to automatically benefit from it.  I'm not
reverting the gdb hack, though.  I'll leave that to the gdb hackers
:-)

Here's the patch I'm checking in, approved by Jim Wilson:

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

[Mark Kettenis]

   From: Jim Kingdon <kingdon@redhat.com>
   Date: 07 Feb 2000 09:08:51 -0800

   > * 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

Well, if there indeed is a considerable amount of code out there that
dlcloses its libraries and people are using GDB to debug it, then we
should raise the priority of fixing this a bit.

   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.

Well, I have looked into this issue (and the more I look into it the
more I'm convinced that the patch is just a quick hack, and a bad one
at that) and I think that we simply have to implement unloading of
shared objects in add_solib, looking at the dynamic linker state and
such.  I havent figured out yet how this would interact with
core-dumps and attach/detach.  There is also the problem that solib.c
is a bit of a maintenance nightmare since it contains some nasty code
to support both SunOS 4 a.out and SVR4 ELF (SunOS 5) shared objects in
one file.  So I decided to work on totally splitting out the code for
ELF shared libs from solib.c.  But that isn't going to lead to very
quick results...

   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.

...and would potentially destabilize things.

   > 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).

The current CVS version in combination with glibc from CVS fails the
thread support tests in the testsuite massively.  I did not have the
time to look into this though.

   > 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).

I'd certainly like to put some of my time into improving i386 support
in GDB, especially since most of this work means improving GDB on the
Hurd too.  And I hope that the patches I sent in the last few months
"prove" this commitment.  A speedup in evaluation and/or integration
of patches would certainly be welcome.  There have been suggestions
like "write-after-approval" access for more people.  Anyway, I'm sure
things will be worked out in the end.

Mark

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

[Daniel Berlin]

>
>What you are really saying here is that is better *not* to get 
something into 
>the tree that everyone can hack at and evenutully get to work.  Instead 
we never 
>incorporate and hope for some miracle that it gets fixed.?.?.?
>
What you are really saying is that it's better to put hacks and crap in 
the tree, and hope someone comes along and does it right, removing the 
hack, while making it even more a living hell for everyone else to 
understand.

>That logic is so completely flawed, that I am surprised you are 
defending it.
So is yours.
>
>We, the ppc people, have seen 4.16.97, 4.17.X, 4.18.X, and now 5.X come 
(or 
>coming) without support because of this "don't break anything 
mentality".  
>
That's not why at all.
You haven't seen support because nobody wants to do it right.

>Simply put isn't it just *better* to get in something and let the users 
help to 
>clean it up, make it work, improve it.  As a professor of TQM, waiting 
for 
>perfection is just not the way to achieve it.  Getting everyone 
involved is.

See, here is your fatal mistake.
You are making the assumption that users will clean it up, make it work, 
and improve it.
While this may be true in other projects, it's not really true in GDB's 
case.
In fact, it's only true in GCC's case because there are more people who 
understand the intricacies of compilers, and who are qualified to hack 
on the compiler, than their are who understand the intricacies of joe 
random platform's debugger interface.
When it comes to things like drivers and debuggers, users don't really 
help much, unless the architecture is so amazingly easy to understand 
it's absurd. Which it isn't. Having ported sound drivers and whatnot to 
BeOS, and talked with quite a few authors of sound drivers on linux, the 
general consensus is that nobody submits patches. Their is the 
occasional person who really enjoys hacking on undocumented hardware, or 
poorly documented debugger interfaces, and who submits patches, but they 
are very very rare.
So what about the non-platform specific parts of GDB that are 
understandable, and hackable?
well, for the most part, they work great, and people are happy with 
them, and thus don't submit patches.
But just ot prove my point, when is the last time you saw a user submit 
a patch for dwarf2 support, or C++ overload resolution (discounting me), 
or support for a new platform?
It just doesn't happen all that often.

Accepting hackish patches won't change this. It's not going to mean 
random people are going to start submitting more patches. It'll just 
mean one more hack in the tree (Although the patch is starting to shape 
up), and one more hack for the occasional few who want to try to 
comprehend how it works, to sort through.

--Dan



-----------------------------------
This message was sent with the demo version of Postmaster, a BeOS mail client.
For more information, please visit http://kennyc.com/postmaster

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

[Jason Molenda]

[-- 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

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

[Daniel Berlin]

> 
> First, Sam's patches just follow what is in solib.c. 
How so?

Their is not any other function in there to determine consistency or
status of libraries.

Sam's is a new type of hook.
Furthermore, i don't see how it's necessary.
Why did he add this consistency hook, to fix a problem that occurs when
you restart.
Why not implement the SOLIB_REMOVE_INFERIOR hook, and rather than the
other implementations, which say they don't disable the breakpoints
(mainly because of their own reasons), disable the breakpoints in those
shared libs.

Does this hook Sam added help anyone else, or add functionality that is
useful to anyone else?
Not really.


 > I don't
think
he > instroduced a new kind of hack. 

He did. There were no other "hacks" to determine whether a list of solibs
was consistent.


> Unless we remove all those "hacks" in
> solib.c in gdb 5.0, I don't think it is a good excuse not to fix the
> bug. 

This is the eventual goal.
Can this bug not be fixed without adding that hook?

>For whoever has to cleanup the "mess" in solib.c, it is just
> another item on the check list. 

So as long as it's an SEP (Someone Elses Problem), it's fine.

And what happens when this hook gets removed in 2 months?
Do you expect the person who removes it, cleaning up solib.c, to fix the
problem the right way then?
> It is the time to make gdb more usable
> than make our lives easier. 
> I hate to see people say gdb 5.0 doesn't
> work right with shared libraries on Linux. 
So fix it without adding another fricking hack.
How do you think things got the way they are in terms of hacks in the
code?
Nobody ever had the time to do the cleanup, instead spending the time on
making it more usable and making lives easier. 
(Not to mention the HP merge, but that's not exactly a standard event)
Don't you understand that?
Unless someone says "enough is enough, i'm putting my foot down, stop
adding hacks, it's becoming unmanageable", it becomes (surprise!)
unmanageable.
 > I'd like to see a firm date
> when the support in gdb for shared libraries will be fixed.

It's funny.
It seems every other platform is making do without this "fix", AFAICT by
bug reports.

> At least,
> I can tell people it will work in xxxx, 2000 and I don't have to make
> my gdb available for Lunux again.


> 
> 
> H.J.
> 

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

[Mark Kettenis]

   Date: Mon, 7 Feb 2000 16:35:27 -0800 (PST)
   From: Daniel Berlin <dan@cgsoftware.com>

   > Debugging shared libraries works most of time with gdb 4.17.0.14.
   > If it doesn't work with 5.0, does that count for serious losses of
   > functionality? I believe many people will be very disappointed
   > if it doesn't unless we can fix it within 2 months.

   You mean for your particular architecture.
   Please don't forget that.
   Debugging shared libs works perfectly fine under BeOS, with my beos port,
   using nothing but the standard solib hooks.

I bet debugging apps that dlopen() a shared object, then dlclose() it
and then dlopen() a different shared object won't work under BeOS
either (if that is possible under BeOS at all), but other than that,
I'm not aware of any deficiencies.

HJ, are you really aware of problems with debugging shared objects
that don't involve a dlclose() somehow?  If you are, could you *please*
provide a testcase.

Mark

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

[Kevin_Hendricks]

Hi,


>The SamL/H.J. patches fix the problem, as far as we can tell here.
>And those patches are not very large.  Is it really so hard to put
>them in and fix the problem the Right Way later?  The argument "we
>can't accept every hack" is pretty weak.  You are not being asked to
>accept every hack, you are being asked to accept a single hack which
>addresses a very serious problem on a major platform.
>
>Just $0.02 from a developer who is tired of manually patching
>prereleases...

I second that motion whole-heartedly.  

And while you are at it, why not fix gdb to actually work with ppc and actually 
really and truly support a major platform (ppc) RIGHT_OUT_OF_THE_BOX god forbid!

I am so tired of fighting with non-working gdb on ppc that gdb has become next 
to useless.  I am now getting hangs with wierd thread errors when debugging 
programs with Franz Sirl's gdb (and his is the *best* one I have found on ppc so 
far).

I know this has been addressed before (but never to my satisfaction) but why can 
patches I submit to the ppc kernel developers, patches to glibc, patches to gcc, 
patches to xfree86, etc *all* be accepted without any further nonsense and 
actually get done while all I ever hear from gdb for every patch that comes 
through the lists is excuses (i.e. one of):

 1. it has to be done right and since we don't have time to do it right
     it can't be done (i.e getting working ppc linux support whether 
     integrated with rs600 support or not!)

 2. patches need to be in the right FSF format or we can't except them
    (what bullshit)

 3. we can't use your patch you have not signed a damn release
    (again why do none of the other FSF project require this).
 
I *never* hear these from any other project.  

Why is gdb so different?  

Why can't it open up it process of getting patches in?  

Why is gdb development not geared to support Linux (any architecture) in any 
reasonable manner?  

So now we will have yet another new major gdb release without things working on 
powerpc (expected!) or even x86 linux???.


No wonder people are forking gdb.  It is the only way to get anything 
accomplished.

Please explain to me why gdb development can't be more like the other major 
projects out there who actually *gladly* accept patches?

Is this too much to ask?


Really?


Kevin

BTW: I want to make this one thing *clear*, I *greatly* appreciate all the hard 
work the gdb maintainers do, the process is simply very very bad and needs to be 
opened up and fixed like yesterday.

--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA   
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959