From mboxrd@z Thu Jan 1 00:00:00 1970 From: patl@cag.lcs.mit.edu (Patrick J. LoPresti) 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> <20000207093417.A10546@lucon.org> <200002071746.MAA22221@devserv.devel.redhat.com> <20000207095901.A10677@lucon.org> <389F6FD1.7BA7FC12@cygnus.com> X-SW-Source: 2000-q1/msg00164.html Andrew Cagney 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 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 To: Love 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: 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 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 To: Grant Edwards 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" To: GDB 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 ----- Delivered-To: hjl@lucon.org Date: Mon, 31 Jan 2000 17:00:17 -0800 From: Sam Lantinga 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 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 + */ + +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 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> <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 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> <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 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: 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: