From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Blizzard To: Jim Kingdon 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: <38ADB9AF.2B472B77@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> <200002182124.QAA13729@devserv.devel.redhat.com> X-SW-Source: 2000-q1/msg00347.html Jim Kingdon wrote: > > > 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 > :-) Yeah, I'm trying the latest snapshot ( marked today. :D ) Doesn't build but the problems look pretty easy to fix. --Chris -- ------------ Christopher Blizzard http://people.redhat.com/blizzard/ I think the mistake a lot of us make is thinking the state-appointed psychiatrist is our "friend." ------------ >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: shebs@shebs.cnchost.com Cc: Jason Molenda , gdb-testers@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: GDB snapshot 2000-01-31 out and IMPORTANT ANNOUNCEMENT Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <3897872C.BA5EF657@cygnus.com> References: <20000131214333.A11195@cygnus.com> <389710D7.6EF7B5A8@shebs.cnchost.com> X-SW-Source: 2000-q1/msg00091.html Content-length: 914 Stan Shebs wrote: > > Jason Molenda wrote: > > > Here is the real crowd pleaser: At the end of the week I am going > > to migrate the active GDB repository from our internal repository > > to sourceware.cygnus.com. This means that all non-confidential[1] > > GDB development done here at Cygnus will be done in full public view. > > You'll be seeing the changes as they are added, warts and all. :-) > > This is great, at long last! Is this going to be separate from the > binutils on sourceware still, or are you going to merge repositories? No. Yes. :-) Jason, who is co-ordinating things with the binutils group, is going to combine the two repositories. As I mentioned in a separate posting there is going to be some fallout and it will take a little time for things to settle down again. At present GDB's bfd is very out-of-date. There are no immediate plans to also combine GCC. enjoy, Andrew >From tromey@cygnus.com Sat Apr 01 00:00:00 2000 From: Tom Tromey To: gdb@sourceware.cygnus.com Subject: Re: Try out the patch database Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <877lfmbkah.fsf@cygnus.com> References: <200002292134.QAA10095@zwingli.cygnus.com> <1000229221310.ZM16579@ocotillo.lan> <38BD61EF.81A4E3C6@marconicomms.com> X-SW-Source: 2000-q1/msg00477.html Content-length: 548 >>>>> "Guenther" == Guenther Grau writes: Guenther> Third, (but not very important) why do you use persistant Guenther> cookies? I don't like cookies und usually disable them, Guenther> but I could live with session cookies, if you really insist Guenther> on them. But persistent cookies that last for a month are Guenther> not what I like. This is a decision made by the gnatsweb authors. I don't know why they did it, and I don't really like it either, but you'd have to take it up with them. Tom >From muller@cerbere.u-strasbg.fr Sat Apr 01 00:00:00 2000 From: Pierre Muller To: Mark Kettenis Cc: gdb@sourceware.cygnus.com Subject: Re: Pascal language support patch preparation Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003021452.PAA02334@cerbere.u-strasbg.fr> References: <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> X-SW-Source: 2000-q1/msg00503.html Content-length: 817 >>The best thing would probably be to port these changes over to the >>p-*.* files. > > Of courseit would, but I would like to stress again that I am a >pascal programmer (a bit assembler also) but that I learned C only to be >able to >add pascal to GDB!!! > > So I am probably not the best person to do this without errors :( I just tried to get the diffs to see how difficult this would be: the diffs are mainly due to the reformating thus it is very difficult to find out where the code really did change!! The logs are also useless as most only are weekly imports from the workers CVS before the CVS was made public! Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99 >From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: patl@cag.lcs.mit.edu 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: <200002081550.QAA19536@landau.wins.uva.nl> 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/msg00167.html Content-length: 2810 From: patl@cag.lcs.mit.edu (Patrick J. LoPresti) Date: 08 Feb 2000 09:55:28 -0500 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*. Depends on what you call broken I guess. Stock GDB 4.17 was pretty usable. 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." I just noticed that the FreeBSD folks seem to have a solution for the dlopen()/dlclose()/dlopen(). It isn't that obscure. It simply isn't implemented. That might take a few hours for a competent GDB hacker, and a few more for somebody who doesn't know GDB too well. But the FreeBSD code looks reasonable at first sight, so I think I can fix things eventually. Just not overnight. Why do people think that breakpoints in shared libraries don't work at all? They didn't work in GDB 4.18, because of a bug-fix for SunOS 4 that broke most of the other systems. That was corrected shortly after the release, and if you use a recent GDB snapshot everything seems to work fine. If you can privide a test-case where setting breakpoints in a shared library breaks things in a recent GDB snapshot, please do so. AFAIK none of the people who're actively hacking on the GDB code is aware of such a problem. 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. Well, the hack is pretty gross, AFAICT only relevant for the multiple dlopen()/dlclose() scenario, and needs some work anyway. Sam provided HJ with two patches that seem to address the same problem, and the code that HJ sent yesterday looks completely bogus to me! The patch affects all platforms using SunOS-style shared libraries or ELF shared libraries. And, can we please first establish what the exact bug is before we start trying to hack around it! Mark >From fnasser@redhat.com Sat Apr 01 00:00:00 2000 From: Fernando Nasser To: Grant Edwards Cc: gdb@sourceware.cygnus.com Subject: Re: RDI target broken in 000215 snapshot Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38B2AD14.7B0B4A4E@redhat.com> References: <20000221104541.A28578@visi.com> X-SW-Source: 2000-q1/msg00369.html Content-length: 1275 Grant Edwards wrote: > > The RDI target support seems to be broken in the 000215 > snapshot. I'm unable to execute any of the eCos test programs, > or any other applictions I've written. (they run fine with a > patched-up 4.18 gdb). I don't know what's wrong with it and > won't have time to look at it for a while. > Can you be more specific? It is working right with the AEB board and with another one I have here. Both use serial ports. I am not using that specific snapshot and I have no idea what sort of problems you may be encountering. There was sort of a code freeze so it should not be much different from others. Please let me know what is your host machine, what version of tools did you use to build gdb, if on cygwin, which version of the dll and, last but not least, what is it that you are getting on the console. > Is somebody currently working on the RDI code? If so, I'll > leave well enough alone until the code stabilizes. > The usual folks. You, myself, Thomas, Nick, Jim... and I build and test it at least twice a week. -- 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 tromey@cygnus.com Sat Apr 01 00:00:00 2000 From: Tom Tromey To: gdb@sourceware.cygnus.com Subject: breakpoint hit counts Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <87ln5w6sh1.fsf@cygnus.com> X-SW-Source: 2000-q1/msg00022.html Content-length: 603 I recently was debugging with gdb and I typed "c 57" instead of "b 57" (a simple typo). I was suprised to learn that gdb preserves the ignore count even when I re-ran my program. I would rather have gdb reset the ignore count when I re-run. As it turns out, the actual rule is that ignore counts are reset unless hit count display is enabled (the default). To me this rule seems obscure, and the feature seems fairly useless. I'd like to change gdb to always clear the ignore count when the inferior is re-run. Any comments on this? Does anybody rely on the current scheme? If so, what for? Tom >From jimb@cygnus.com Sat Apr 01 00:00:00 2000 From: Jim Blandy To: Kevin Buettner Cc: gdb@sourceware.cygnus.com Subject: Re: Try out the patch database Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <200002292134.QAA10095@zwingli.cygnus.com> <1000229221310.ZM16579@ocotillo.lan> X-SW-Source: 2000-q1/msg00472.html Content-length: 746 > > Take a look at http://sourceware.cygnus.com/gdb/contribute.html , and > > let me know what you think. > > I see two patches in the gdb database. (There was only one a little > while ago.) I'd like to see how the attachment mechanism works. I > downloaded the Kublai Khan poem, but it's in html. I'd like to see > a real patch that I can download. > > Also, I think it'd be useful to be able to view a patch in the web > browser as well as download it to a file. It's not clear to me that > both of these capabilities are available. This is an area of concern for me, too. If you look at gdb-patch/7, there's some weirdness going on with the indentation that I'm not happy with. I think the gnatsweb script may require some hacking. >From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: hjl@valinux.com Cc: gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: A revised patch for dlclose Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003080058.e280wga00453@delius.kettenis.local> References: <20000307120800.A27315@valinux.com> X-SW-Source: 2000-q1/msg00578.html Content-length: 918 Date: Tue, 7 Mar 2000 12:08:00 -0800 From: "H . J . Lu" Here is a revised patch for dlclose. If you take a look at the dynamic linker in glibc 2.1 or above, you will find that it informs gdb about loading/unloading a shared library via an internal debug function, _dl_debug_state (). gdb already handles the loading in handle_inferior_event () with BPSTAT_WHAT_CHECK_SHLIBS and BPSTAT_WHAT_CHECK_SHLIBS_RESUME_FROM_HOOK. However, we need also check the unloading event. solib_verify () will be called only when the dynamic linker calls _dl_debug_state (). It shouldn't introduce any overhead. I believe it is on the right track although it may be further optimized. HJ, please stop wasting your time pushing this patch. The patch has several bad points, that you cannot fix without considerable changes to the way solib.c handles and caches the link map. Mark >From Peter.Schauer@regent.e-technik.tu-muenchen.de Sat Apr 01 00:00:00 2000 From: "Peter.Schauer" To: mark@codesourcery.com (Mark Mitchell) Cc: kingdon@redhat.com, donnte@microsoft.com, gdb@sourceware.cygnus.com Subject: Re: Regressions problem (200 failures) Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003021143.MAA14294@reisser.regent.e-technik.tu-muenchen.de> References: <20000302023420H.mitchell@codesourcery.com> X-SW-Source: 2000-q1/msg00494.html Content-length: 935 > Peter> For practical debugging purposes (especially C++), the line > Peter> number information (and thus the breakpoint) has to be put > Peter> before the initialization code for local variables, so that > Peter> we can debug object initialization. > > But the line number itself doesn't have to indicate the `{'; it could > indicate the next line, if that's what GDB wants. This is more > possible than it used to be since the C++ front-end now puts out whole > functions at once, rather than processing a statement at a time. > > Still, it's non-trivial. >From a pure user perspective (for now not considering implementation problems with GCC or GDB), a breakpoint on the opening brace is not what I want, as I will almost always have to step over it. I'd expect a breakpoint on the first local variable that needs initalization, or the first statement. -- Peter Schauer pes@regent.e-technik.tu-muenchen.de >From gatliff@haulpak.com Sat Apr 01 00:00:00 2000 From: William Gatliff To: gdb@sourceware.cygnus.com, crossgcc@sourceware.cygnus.com Subject: Re: gdbstubs library posted at sourceforge Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <3891C982.32326D7E@haulpak.com> References: <200001271910.OAA04242@devserv.devel.redhat.com> X-SW-Source: 2000-q1/msg00069.html Content-length: 4682 Jim: Jim Kingdon wrote: > > I just moved my gdbstubs library to sourceforge.net. > > Cool! I've added a link from http://sourceware.cygnus.com/gdb/ - at the > bottom of the page with the other links. Thanks! > > The release license is LGPL. > > Are you sure you want this rather than public domain (as the stubs in the > GDB distribution) or XFree86-style? I suppose maybe it is a moot point > if people leave out the stubs when they actually ship code, but in > general, the LGPL's requirement that people make available .o's makes it > somewhat impractical for many embedded applications. Actually, that's a good question. The following are my concerns, which I think the LGPL addresses, although not perfectly. I'm open to differing opinions and suggestions, though, as I'm no expert: * I want to encourage leaving the stubs in production embedded systems * I don't want to force users to divulge the non-gdbstubs parts of their application if they don't want to * I want to avoid proprietary, closed-source modifications to the stubs; minor tweaks to overcome hardware and security issues are fine, but nothing that makes it work better with gdb than the public sources * I want to encourage contributions to the stubs * I don't want someone turning gdbstubs itself into a closed source product (particularly the tracepoint stuff, when it arrives) Straightaway, the first, second and last points seem to rule out GPL. My problem with the public domain distribution of the gdb-distributed stubs is that they don't encourage the kind of thing I'm doing--- cooperative building of more advanced stubs, to try and make gdb an increasingly attractive debugger for embedded systems. The MIT license seems to have a similar problem, in that it allows users to modify gdbstubs without returning those modifications to the community. As I understand it, linking an LGPL work with a proprietary application doesn't force one to divulge the source for the application, but they must divulge modifications to the LGPL'd work, so I'm pretty good so far. The .o requirement would come up if someone wanted to update the stubs without updating the application, but that doesn't seem like a circumstance that's likely to come up, at least not on the kinds of embedded systems I'm familiar with. [note: this is an open invitation for experiences to the contrary!] So, it still seems ok, at least in my current world. Maybe CEPL is a closer fit for what I'm after, because it accomplishes everything the LGPL does *and* eliminates the need for .o's? I could go there. I suppose that I can also offer alternate licenses for people who want to make proprietary modifications, but I'm hesitant to do so because: * it's a headache, and I don't want to pay that much attention to the process * I don't want to get into disputes over ideologies with contributors * I'm having trouble seeing what a "proprietary" extension might actually be * I don't want "forks" of proprietary extensions with nifty features not found in the public code base * it's just not good karma :^) Several other people have expressed concerns with the LGPL to me privately. I would appreciate said people (you know who you are!) making the background for their objections known publicly, so that we can arrive at a workable solution. I'll follow consensus as long as it's the most realistic solution available for the motivations I list above. Myself, I don't think I have a problem with LGPL because I don't intend to make proprietary mods to gdbstubs, and I don't expect my clients (who get source anyway) or customers (who wouldn't know what to do with it) to want to update their stubs. My products don't ship with stabs information either, so the stub is of little value except for engineering-level testing. I admit that my avoiding the possiblity of a .o distribution doesn't really eliminate it, however... I am PERFECTLY HAPPY to select a different license, as long as it's one that doesn't permit proprietary mods to gdbstubs itself. Ideas? > > I'll also take any suggestions on how to manage the project--- I'm not > > exactly skilled in the art of extreme multitarget development, at > > least not yet. :^) > > You've already done the hard part by being dumb ^H^H^H^H brave enough to > start the project! Feel free to ask if you have specific questions. LOL. :^) How about pointers to a tutorial on configure? Seems like it would be nice to be able to do 'configure --target=x-y-z', but maybe that's overkill. b.g. -- William A. Gatliff Senior Design Engineer Komatsu Mining Systems To teach is to learn.