From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: kevinb@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: Patches for GNU/Linux PPC native now in CVS Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002241047.LAA02405@landau.wins.uva.nl> References: <1000222025201.ZM9805@ocotillo.lan> <200002221013.e1MAD3A00261@delius.kettenis.local> <1000224102541.ZM14031@ocotillo.lan> X-SW-Source: 2000-q1/msg00398.html Date: Thu, 24 Feb 2000 03:25:41 -0700 From: Kevin Buettner On Feb 22, 11:13am, Mark Kettenis wrote: [Detailed failure analysis snipped] > Anyway, I hope this helps, It did indeed. Thanks! (It showed me where not to focus my attention first.) I'll respond to the sourceware list when I've had more time to study your analysis, but in the meantime, I wanted to send you a note to let you know that I appreciated your analysis... Meanwhile, I learned something more about the gdb.base/annota1.exp: backtrace @ signal handler failure I reported. There is nothing wrong with the test per se. It's just that on my i586-pc-linux-gnu system the regexp matching takes an awful lot of time. Setting the timeout to 10 minutes made the test pass. This is probably related to the fact that with glibc there is an extra frame. Apparently the fix I suggested (but didn't understand), speeded up the regexp matching somewhat, but even in that case (with the default timeout) the test failed on my system last night. Sorry for the confusion. I just couldn't imagine the regexp matching taking the better part of 10 minutes :-(. Mark >From cgf@cygnus.com Sat Apr 01 00:00:00 2000 From: Chris Faylor 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: <20000308175739.B12038@cygnus.com> References: <200003082121.e28LLRu05681@delius.kettenis.local> <1000308222742.ZM8876@ocotillo.lan> <20000308173031.A11900@cygnus.com> <1000308225132.ZM8953@ocotillo.lan> X-SW-Source: 2000-q1/msg00625.html Content-length: 562 On Wed, Mar 08, 2000 at 03:51:32PM -0700, Kevin Buettner wrote: >...18-char names, so if you add a ~ for backups, ls can still list >files in four columns. Weak rationale perhaps, but there's no other >technical limitations, and so the criterion can be usability. Personally, I would chose clarity of the name over the fact that ls output can fit in four columns. But then, I think the gdb directory is in drastic need of a reorg, too. Maybe if we had something like a 'tdep' directory instead of i386-linux-tdep.c we wouldn't have to worry about this. cgf >From Franz.Sirl-kernel@lauterbach.com Sat Apr 01 00:00:00 2000 From: Franz Sirl To: "Daniel Berlin" Cc: khendricks@admin.ivey.uwo.ca, 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: <00020900262503.05214@enzo.bigblue.local> X-SW-Source: 2000-q1/msg00178.html Content-length: 2598 >>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? Well, the point is that there is a patch out there by Kevin Buettner that once was done in late 4.16 I think. It wasn't applied for 4.17 for legal reasons which have since then be resolved (post the 4.18 release). But since then nothing has been checked in into CVS (which could be somehow understandable), but also no intermediate work has been posted on gdb-patches :-(. Se we know there's something out there that is being worked on, but we cannot take part in development, because there's nothing we can iterate on! We can only sit and wait in this situation, or? And I think it's quite understandable that we get a bit "nervous" when a new release is announced without support for Linux/PPC. In fact, if Kevin Hendricks wouldn't have been faster than me, I would have started this discussion :-)). I think Kevin Buettner should checkin his current status into CVS, so that there is at least _something_ we can report bugs against and maybe even do some fixes. Franz. >From fnasser@redhat.com Sat Apr 01 00:00:00 2000 From: Fernando Nasser To: gdb@sourceware.cygnus.com, jtc@redback.com, Andrew Cagney , taruna@redhat.com, Eric Bachalo Subject: Remote protocol extension for register ranges Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38D8CFA4.C3535C93@redhat.com> X-SW-Source: 2000-q1/msg00770.html Content-length: 1276 Presently, the remote protocol can only read all registers of a target. This is OK for the context registers (the ones that are saved by the OD on a context switch) but this is a serious limitation for machines that have lots of additional registers. It is just not feasible to read them all at every "g" packet. I would like to add parameters to the "g" packet. Something similar has been proposed before -- the only difference is that I would like the parameters to be a register number or a register number range range. For instance: g82 Reads register 82 g31-40 Reads registers 31-40 Gdb would test for the acceptance of these types of packets by the stub and fall back to the less efficient form if not (like it does for "P" packets). I really need this feature as do other people that are dealing with one of the numerous microprocessors that have too many extra registers. And it is becoming quite urgent now. What is the current thinking about this? Are there other proposals I am not aware of? What are the maintainers position? -- Fernando Nasser Red Hat, Inc. - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: memory region attribute CLI Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003160944.EAA01842@indy.delorie.com> References: <5mr9dd5dlt.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00718.html Content-length: 424 > * create memory region: > > mem attribute [attribute ...] > > example: > (gdb) mem 0x00008000 0x0000FFFF ro 8 > (gdb) mem 0x00007FF0 0x00007FFF rw > (gdb) mem 0x00007FE0 0x00007FEF wo 16 > (gdb) mem 0x00007FD0 0x00007FDF ro Could you please point to the discussions about this feature? I find it hard to understand what would be the usage of the memory regions. >From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: muller@cerbere.u-strasbg.fr Cc: gdb@sourceware.cygnus.com Subject: Re: RFD: New command to inspect other selectors memory. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003031240.e23CeRn00162@delius.kettenis.local> References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003030843.JAA12246@cerbere.u-strasbg.fr> X-SW-Source: 2000-q1/msg00519.html Content-length: 1571 Date: Fri, 03 Mar 2000 09:27:14 +0100 From: Pierre Muller I inserted this in a reply about pascal extension, but as I got no answer, I thought I will send it as a separate message. Sorry about that. I have written for DJGPP target a relatively small patch. It allows to read memory from another selector this was very useful for me when I tried to debug the debugger itself and when I added exception support fro GDB on DJGPP ! This patch consists of the addition of one command that I called "xx" which is a simple clone of the "x" command but can take a selector as for intance "xx $fs:0x400" then the next "xx 0x800" keeps using the last selector value. I do not know if this could be interesting for other i386 targets (maybe for win32 to be able to see the content of the $fs selector that contains the exception chain, but I am not sure how if its readable inside a win32 API program). Is such kind of patch too specific to have any chance to get accepted ? I don't know if it could be of any use for other processors or operating system !! This may be impossible to implement on most i386 targets (with the possible exception of Solaris and Mach-based targets), but nevrtheless it could be useful to have for things that are a bit more low-level (like debugging a threads library that uses segmentation to store per-thread data and such). The suggested syntax could probably be improved, since "xx" isn't very descriptive. People with bright ideas? Mark >From jsm@cygnus.com Sat Apr 01 00:00:00 2000 From: Jason Molenda To: gdb@sourceware.cygnus.com, gdb-testers@sourceware.cygnus.com Subject: New GDB CVS repository is set up! Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000206224315.A25084@cygnus.com> X-SW-Source: 2000-q1/msg00119.html Content-length: 3832 Hi folks! The new GDB repository is set up. If you have a checked out copy of the GDB repository, you're going to check out a brand new one. Read this whole message. This weekend I merged the GDB repository with the binutils repository which was already on Sourceware. For those of you working on both gdb and binutils, the merging of these two will ease your life considerably. I treated the binutils repository as the master repository, so whenever there was overlap between the gdb repository and the binutils repository, the files from the binutils repository were used. Binutils and GDB have not been synchronized/merged in approx six months, so we're going to have some instability this week. Cygwin support in binutils is just plain broken right now. :-/ The following directories from the GDB repository were incorporated in to the new repository with no changes: dejagnu, expect, gdb, mmalloc, readline, sim, tcl, utils The following directories from the binutils repository were incorporated in to the new repository with no changes: bfd, config, etc, gas, gprof, include, intl, ld, libiberty, opcodes, texinfo And all of the top-level files were from binutils as well. If you have changes in your checked-out tree, and the changes are all in the directories that came from GDB, you are fine -- do a cvs diff of your existing tree, check out a new tree and apply the patches. They'll apply cleanly. If you have changes in your checked-out tree in the directories from the binutils repository, you should still do the diff in the old GDB repository so you have a clear idea of what you changed, but the changes may not apply cleanly to the binutils version of that directory. You may need to do some work to get it applied cleanly. Most people will have few, or no, changes to their checked out copy of the GDB repository. Those people should just remove their checked out copy and get a new one. Andrew Cagney suggested that a lot of people will do this, so I've tarred up pre-checked-out trees using the anoncvs pserver method -- just download one of these tarfiles and you'll be good to go. In ftp://sourceware.cygnus.com/pub/gdb/snapshots/ you'll find: 9102999 Feb 6 19:38 gdb-pserver-2000-02-06.tar.bz2 2230176 Feb 6 19:42 dejagnu-pserver-2000-02-06.tar.bz2 11027699 Feb 6 20:01 gdb-dejagnu-pserver-2000-02-06.tar.bz2 14246962 Feb 6 20:20 insight-pserver-2000-02-06.tar.bz2 The "gdb-pserver-2000-02-06.tar.bz2" is just GDB. The "dejagnu-pserver-2000-02-06.tar.bz2" is just dejagnu. The "gdb-dejagnu-pserver-2000-02-06.tar.bz2" is GDB and dejagnu. The "insight-pserver-2000-02-06.tar.bz2" is Insight. If you want to check out a tree for yourself, the instructions on the GDB web page ( http://sourceware.cygnus.com/gdb/ ) are updated. In short, you want to do cvs -z9 -d :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src login ("anoncvs" for the password) cvs -z9 -d :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src co gdb As I wrote previously, changes to the GDB repository will now happen almost entirely in this public repository. If you want to see cvs commit messages as they happen, sign up to the gdb-cvs mailing list (there are instructions on the GDB home page for getting on this) or monitor its web archive. Much credit for this repository move goes to Andrew Cagney who has been moving (literally) mountains of code in the face of lame Australian infrastructure :-) and an already heavy work load. This move would have been a disaster without the overdue reorganizations and cleanups he did last week. Thanks Andrew! This is a significant change, and I expect some people to have problems. I doubt I've thought of every possible confusion or complication in this move. Ask me if you have any questions. Jason Free the Software! >From toddpw@windriver.com Sat Apr 01 00:00:00 2000 From: Todd Whitesel To: jsm@cygnus.com (Jason Molenda) Cc: gdb@sourceware.cygnus.com (GDB Developers) Subject: Re: GDB ftp site in hyperspace ... Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002010659.WAA04719@alabama.wrs.com> References: <20000131225201.A11482@cygnus.com> X-SW-Source: 2000-q1/msg00083.html Content-length: 604 > (I'm not joking about the Solaris ftp client being broken; I think it > will still work if there is at least one file in a given directory. The > directory you're looking at has no files in it, only subdirectories) Think you could stick a content-free README in there then?? I can't imagine you enjoy the prospect of having to answer this question more than a few times, unless you simply enjoy bagging on Solaris. (This I can understand, but still...) FWIW I run NetBSD at home; at work my options right now are Solaris and NT -- obvious choice there ... -- Todd Whitesel toddpw @ windriver.com >From khendricks@ivey.uwo.ca Sat Apr 01 00:00:00 2000 From: Kevin Hendricks To: dan@cgsoftware.com 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: <00020823060800.00592@localhost.localdomain> References: <950048577_PM_BeOS.dan@cgsoftware.com> X-SW-Source: 2000-q1/msg00183.html Content-length: 2478 Hi, > 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. Why is eveything "not perfect" considered a hack or crap? I for one don't think Kevin Buettner's patch is a hack or crap at all. Please stop equating what we want to see added with crap. > 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. I think your attitude here is just wrong (and frankly part of the whole gdb problem). You obviously think you have cornered the market on some unique programming skill. This is simply not true. Users can and will help. I would help (I was part of Blackdown's jdk porting team until recent events forced me to move on), Franz would help (he is *the* gcc person for ppc and without his work with them we (ppc) would still be in the dark ages, Gary Thomas would help (he is really the father of the whole linux ppc movement and is single handedly responsible for much of the code that ppc uses), etc. We just need something to start playing with. As it stands, we can't even submit official bug reports. Please stop thinking that gdb is so complex that only a maintainer can help (seen the inside of many multi-threaded virtual machines latesly?). Sure we won't be as good as you, we won't be as productive as you, but we (and others) really can help. I think we are proof of that. Unfortunately when I submitted the original ppc patch (based on Kevin Buettner work) back around 4.16 or earlier, I just never dreamed it would take this long to get anything there done with it. Perhaps cygnus plays too large a role in tool development. Perhaps open source tools should not be tied so closely to any one company. Too many conflicts of interest? Too many paying customers versus the rest of us? I just don't know. But whatever the outcome, please stop assuming that all "users" are idiots. This is simply not the case and results in much of the bad or negative "mindset" I have seen in the gdb lists and tried to point out to Stan. Thanks for responding to my post. I am not sure we will ever agree on how things should be done but we are talking about it which is more than has been done of late. Take care, Kevin >From Peter.Schauer@regent.e-technik.tu-muenchen.de Sat Apr 01 00:00:00 2000 From: "Peter.Schauer" To: kettenis@wins.uva.nl (Mark Kettenis) Cc: gdb@sourceware.cygnus.com Subject: Re: Testsuite regression Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003261941.VAA32661@reisser.regent.e-technik.tu-muenchen.de> References: <200003261706.e2QH6Yn08493@delius.kettenis.local> X-SW-Source: 2000-q1/msg00812.html Content-length: 2275 I noticed this to, it is caused by: 2000-03-14 Elena Zannoni * gdb.base/printcmds.c: Add typedeffed arrays. which now puts a nonzero word after ctable2 in gdb.base/printcmds.c via ArrayInt a1 = {2,4,6,8,10,12,14,16,18,20}; Previous versions had int int1dim[12] = {0,1,2,3,4,5,6,7,8,9,10,11}; after ctable2, putting a zero word there. So we now have a non zero byte after ctable2 (but only on little endian targets). p &ctable2[15*16] asks GDB to print an unsigned char pointer and GDB puts out the contents of the pointer as a string as well. As the string is no longer zero terminated, GDB appends ellipsis. It could be fixed by appending a zero byte to ctable2 (but I have tested this only lightly): *** gdb/testsuite/gdb.base/printcmds.c.orig Wed Mar 22 19:08:22 2000 --- gdb/testsuite/gdb.base/printcmds.c Sun Mar 26 21:34:20 2000 *************** *** 53,59 **** 'a','a','a','a','a','a','a','a','a','a','a','a','a','X','X','X', 'a','a','a','a','a','a','a','a','a','a','a','a','a','a','X','X', 'a','a','a','a','a','a','a','a','a','a','a','a','a','a','a','X', ! 'a','a','a','a','a','a','a','a','a','a','a','a','a','a','a','a' }; /* Single and multidimensional arrays to test access and printing of array --- 53,59 ---- 'a','a','a','a','a','a','a','a','a','a','a','a','a','X','X','X', 'a','a','a','a','a','a','a','a','a','a','a','a','a','a','X','X', 'a','a','a','a','a','a','a','a','a','a','a','a','a','a','a','X', ! 'a','a','a','a','a','a','a','a','a','a','a','a','a','a','a','a', 0 }; /* Single and multidimensional arrays to test access and printing of array > Hi all, > > Somewhere between March 9 and March 15, the following failure appears: > > FAIL: gdb.base/printcmds.exp: p &ctable2[15*16] with print elements set to 16 > > This is the output from a run where the test still passed: > > p &ctable2[15*16] > $538 = (unsigned char *) 'a' > > And this the current output: > > p &ctable2[15*16] > $538 = (unsigned char *) 'a' ... > > I'm a bit puzzled though what change is responsible for this > regression. Is there anybody else observing this failure? > > Mark -- Peter Schauer pes@regent.e-technik.tu-muenchen.de >From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon To: blizzard@redhat.com Cc: kettenis@wins.uva.nl, gdb@sourceware.cygnus.com Subject: Re: problems with gdb Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002182124.QAA13729@devserv.devel.redhat.com> References: <38A47E89.3F4674B3@mozilla.org> <38AB2DC4.FA9A3C71@redhat.com> <87zot0y99f.fsf@cygnus.com> <38AC0B97.19AE4BAE@mozilla.org> <38AD8469.27616453@redhat.com> <200002181916.e1IJGuA00449@delius.kettenis.local> <38ADA340.DF649E22@redhat.com> <200002182034.e1IKYlf00214@delius.kettenis.local> <38ADB0B9.4D4D6F10@redhat.com> X-SW-Source: 2000-q1/msg00346.html Content-length: 886 > I think that the version that I have is based on a snapshot from 19991004. > Jim should know more. Jim? You are working off the gdb-4.18-10.src.rpm which is in Red Hat Linux 6.2beta? While I am interested in knowing whether that version is totally broken for multi-threads (when combined with glibc and everything else from 6.2beta), I've given up on making it usable for Mozilla (given that 6.2beta is already frozen and the number of mozilla developers is small compared with the total number of people using Linux). I just don't see how to do it without too much risk of breaking something else. The key task is in getting GDB in CVS fixed. You just told me to get Mozilla from CVS (it is building now, I know because the fan on my laptop is in high speed mode and will be for the next hour or so :-)) so turnabout is fair play and I can tell you to do the same for GDB :-) >From dan@cgsoftware.com Sat Apr 01 00:00:00 2000 From: Daniel Berlin To: Grant Edwards Cc: Daniel Berlin , gdb@sourceware.cygnus.com Subject: Re: Dwarf Error: Could not find abbrev number 1. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <20000311140313.A32545@visi.com> <20000311152157.A640@visi.com> X-SW-Source: 2000-q1/msg00679.html Content-length: 740 Grant Edwards writes: How old is the old binutils? There seem to be some LMA related changes to ld from 02-16-99, that would have affected arm-elf. --Dan > On Sat, Mar 11, 2000 at 01:06:17PM -0800, Daniel Berlin wrote: > > > You have both stabs and dwarf debug info in the same executable? > > I guess so. I have whatever arm-elf-gcc -g generates. > > > (It's rhetorical, the .stab section confirms it) This is most > > likely the problem. > > It turns out that removing the .stab sections makes no difference. > > What fixes things is forcing the VMA/LMA of all of the .debug_* > sections to 0. (Regardless of the presence of the .stab > sections). Perhaps this was the default behavior of the older > binutils? >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: shebs@apple.com, "K. Richard Pixley" Cc: gdb@sourceware.cygnus.com Subject: Re: test suites? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38D5BA28.94F9A2EC@cygnus.com> References: <200003162238.OAA19924@wicket.microunity.com> <38D2955A.8236559A@apple.com> X-SW-Source: 2000-q1/msg00742.html Content-length: 930 Stan Shebs wrote: > > "K. Richard Pixley" wrote: > > > > What are people using for regression testing on gdb these days? > > The same old testsuites that we were using when you were at Cygnus! > > OK, there have been some additions and restructuring, but the > theory is unchanged; they all live under src/gdb/testsuite, > you get a recent dejagnu and install, then do "make check" in > your objdir. To expand a little. Dejagnu is included in the nightly shots (gdb+dejagnu.tar.gz,...) or as a separate file. Alternativly, you can check it out, along with GDB, vis: cvs -z9 -d :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src co gdb dejangu This ensures that the dejagnu you test GDB with is the same one that everyone else is using. Andrew PS: which reminds me, now that nightly snapshots are working (....) I need to start a discussion on what the snapshots should contain. ftp://sourceware.cygnus.com/pub/gdb/snapshots/ >From pici@flatline.koli.uni-miskolc.hu Sat Apr 01 00:00:00 2000 From: Jonyer Otto To: gdb@sourceware.cygnus.com Subject: Re: symbol table architecture problems Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: X-SW-Source: 2000-q1/msg00009.html Content-length: 259 Helo! Now I can see, that gdb has hash.c and good functions in it but it does not seem using it so efficient because of the too much strcmp()s. If someone knows how could I increase the efficacy somehow. (I countinue looking at the sources and docs) Pici From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: kevinb@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: Patches for GNU/Linux PPC native now in CVS Date: Thu, 24 Feb 2000 02:47:00 -0000 Message-ID: <200002241047.LAA02405@landau.wins.uva.nl> References: <1000222025201.ZM9805@ocotillo.lan> <200002221013.e1MAD3A00261@delius.kettenis.local> <1000224102541.ZM14031@ocotillo.lan> X-SW-Source: 2000-02/msg00004.html Message-ID: <20000224024700.NgwSQXZnC51jK39axfd1alZjgbDD0cyk3KFBYikH4YQ@z> Date: Thu, 24 Feb 2000 03:25:41 -0700 From: Kevin Buettner On Feb 22, 11:13am, Mark Kettenis wrote: [Detailed failure analysis snipped] > Anyway, I hope this helps, It did indeed. Thanks! (It showed me where not to focus my attention first.) I'll respond to the sourceware list when I've had more time to study your analysis, but in the meantime, I wanted to send you a note to let you know that I appreciated your analysis... Meanwhile, I learned something more about the gdb.base/annota1.exp: backtrace @ signal handler failure I reported. There is nothing wrong with the test per se. It's just that on my i586-pc-linux-gnu system the regexp matching takes an awful lot of time. Setting the timeout to 10 minutes made the test pass. This is probably related to the fact that with glibc there is an extra frame. Apparently the fix I suggested (but didn't understand), speeded up the regexp matching somewhat, but even in that case (with the default timeout) the test failed on my system last night. Sorry for the confusion. I just couldn't imagine the regexp matching taking the better part of 10 minutes :-(. Mark >From khendricks@ivey.uwo.ca Thu Feb 24 05:56:00 2000 From: Kevin Hendricks To: Kevin Buettner , khendricks@ivey.uwo.ca Cc: gdb@sourceware.cygnus.com Subject: Re: Patches for GNU/Linux PPC native now in CVS Date: Thu, 24 Feb 2000 05:56:00 -0000 Message-id: <00022408590700.29946@localhost.localdomain> References: <1000222025201.ZM9805@ocotillo.lan> <00022221542500.09439@localhost.localdomain> <1000224101226.ZM14012@ocotillo.lan> X-SW-Source: 2000-02/msg00005.html Content-length: 1523 Hi Kevin B. > > Everything was working fine until I decided to rerun the program > > from within gdb without removing my shared library breakpoints > > first. > > Does it work if you disable your shared library breakpoints first? I just tried it again (repeatedly) and I could not recreate the problem at all either way (with or without disabling breakpoints first). Now gdb just politely disables the breakpoints it can't enable in shared libraries and I just manually enable them later. So I think this problem is caused either by stack/memory corruption or some variable not being initialized properly. It seems to be quite random. I will keep playing with gdb and the jdk and let you know what is up. If it happens again, I will definitely try to get a pure c program that exhibits the same problems. > BTW, I just fixed one of the bugs (there were actually two separate bugs) > which was causing one of the shared library tests to fail. I'll commit > this fix later on today, but I doubt it will solve your problem. I will update my cvs tree tomorrow. Again thanks for all your help. I just need to play around with it some more under native threads to make sure some of the old problems have not cropped back up. Overall a very big improvement! Thanks, Kevin -- 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