From mboxrd@z Thu Jan 1 00:00:00 1970 From: Donn Terry To: "'gdb@sourceware.cygnus.com'" Cc: "'mark@codesourcery.com'" Subject: Regressions problem (200 failures) Date: Wed, 01 Mar 2000 09:49:00 -0000 Message-id: X-SW-Source: 2000-03/msg00010.html Andrew has asked me to see if there are others affected by this... On 2/17, the following patch was made to gcc: > 2000-02-17 Mark Mitchell > > * function.c (thread_prologue_and_epilogue_insns): Put a line note > after the prologue. It has the effect, in my case at least, of causing gdb to break at the "{" of many functions when breaking at a function name (5 of 5 main()s that I tried, but not too many other functions). (Usually gdb breaks breaks at the first statement rather than somewhere in the function prologue). I discussed this with Mark Mitchell, and he concurs that that could be a side-effect of the patch (whose purpose is to assure that SOME breakpoint occurs at the beginning of each function). That, in itself, isn't a problem (except possibly with user perception). However, the gdb regressions are written in such a way that they expect to stop at the first statement (and often do a single "n", expecting the first statement to be executed). This causes well over 200 (mostly cascade) regression failures. Andrew asserts that the regressions aren't being too picky in this regard because of user expectation. The problem for me is I suspect that they're BOTH right, but there are regression failures unless something happens. Are there others out there who are seeing this (run the regressions pointing it at a new gcc)? (The gcc CVS as of 5:30 or so PST last night still exhibited the problem.) Does anyone have any thougts on how to proceed? Donn Terry Speaking, of course, only for myself. >From Guenther.Grau@marconicomms.com Wed Mar 01 10:31:00 2000 From: Guenther Grau To: gdb@sourceware.cygnus.com Subject: Re: Try out the patch database Date: Wed, 01 Mar 2000 10:31:00 -0000 Message-id: <38BD61EF.81A4E3C6@marconicomms.com> References: <200002292134.QAA10095@zwingli.cygnus.com> <1000229221310.ZM16579@ocotillo.lan> X-SW-Source: 2000-03/msg00011.html Content-length: 602 Hi, > > > Take a look at http://sourceware.cygnus.com/gdb/contribute.html , and > > > let me know what you think. I have a few comments on this. First of all: great to have a bug database online! Second, why is the category named gdb-patches instead of gdb? Is it not intended for people to report bugs? Is it only for patches? Third, (but not very important) why do you use persistant cookies? I don't like cookies und usually disable them, but I could live with session cookies, if you really insist on them. But persistent cookies that last for a month are not what I like. Thanx, Guenther >From tromey@cygnus.com Wed Mar 01 11:00:00 2000 From: Tom Tromey To: gdb@sourceware.cygnus.com Subject: Re: Try out the patch database Date: Wed, 01 Mar 2000 11: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-03/msg00012.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 mark@codesourcery.com Wed Mar 01 12:26:00 2000 From: Mark Mitchell To: donnte@microsoft.com Cc: gdb@sourceware.cygnus.com Subject: Re: Regressions problem (200 failures) Date: Wed, 01 Mar 2000 12:26:00 -0000 Message-id: <20000301123337B.mitchell@codesourcery.com> References: X-SW-Source: 2000-03/msg00013.html Content-length: 677 >>>>> "Donn" == Donn Terry writes: Donn> regressions pointing it at a new gcc)? (The gcc CVS as of Donn> 5:30 or so PST last night still exhibited the problem.) Donn> Does anyone have any thougts on how to proceed? I have one. (I communicated this to Donn privately, so this is for the list.) I think GCC shouldn't put out any line notes for the prologue in the first place. That's what's causing the problem, indirectly. Does GDB require a line note in the prologue, or can we wait until the first bit of real code? -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com >From kingdon@redhat.com Wed Mar 01 13:48:00 2000 From: Jim Kingdon To: "Sharath Kumar" Cc: gdb@sourceware.cygnus.com Subject: Re: about breakpoints Date: Wed, 01 Mar 2000 13:48:00 -0000 Message-id: References: X-SW-Source: 2000-03/msg00014.html Content-length: 568 > Can anyone give me some detailed info about how breakpoints are > implemented in gdb? I have the gdb source, but if you have some docs > it will be great. That's not a very specific question, but there is a good introduction in doc/gdbint.texi in the GDB distribution. Also see: breakpoint.c in GDB "man ptrace" and/or "man proc" depending on your OS If the documentation you want doesn't exist, you might consider tracking down information and writing documentation (and publishing it via http://www.oswg.org/ or something) - that can be a good way to learn. >From ac131313@cygnus.com Wed Mar 01 14:16:00 2000 From: Andrew Cagney To: GDB Discussion , GDB Patches Subject: [MAINT] Daniel Berlin is C++ language maintainer Date: Wed, 01 Mar 2000 14:16:00 -0000 Message-id: <38BD967B.CD2AF9F8@cygnus.com> X-SW-Source: 2000-03/msg00015.html Content-length: 336 Hello, I'm very pleased to announce that Daniel Berlin has agreed to take on the responsibility of C++ language support within GDB. As many are probably aware, Dan's been contributing a flurry of patches that fix numerous C++ problems for some time. Nice day for it! Andrew C++ language support Daniel Berlin dan@cgsoftware.com >From kingdon@redhat.com Wed Mar 01 14:30:00 2000 From: Jim Kingdon To: gdb@sourceware.cygnus.com Subject: Re: Dependence on config.status Date: Wed, 01 Mar 2000 14:30:00 -0000 Message-id: References: <200002280657.BAA27090@indy.delorie.com> <38BCCA84.74A4143E@cygnus.com> X-SW-Source: 2000-03/msg00016.html Content-length: 816 > > Why does GDB need to be dependent on config.status, in addition to > > config.h? > > I don't know and yes I agree with you. I think it is just history. Well, if memory serves, if you re-ran configure in such a way that tm.h started linking to a different file, then the config.status dependency was the only way to force a rebuild. I think that is still true (at least, I glanced through the Makefile.in and configure.in and that's what it looked like). Having said that, there is sometimes a tradeoff between having dependencies correct and having them useful. Making people type "make clean" in certain obscure situations may not be all that bad (although it tends to be pretty confusing as you usually don't realize what is going on until GDB is acting in strange and inexplicable ways). >From kettenis@wins.uva.nl Wed Mar 01 15:40:00 2000 From: Mark Kettenis To: ac131313@cygnus.com Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: [MAINT] x86 maintainers ..... Date: Wed, 01 Mar 2000 15:40:00 -0000 Message-id: <200003012340.e21Ne6o00157@delius.kettenis.local> References: <38BCA2B9.3BDE66AD@cygnus.com> X-SW-Source: 2000-03/msg00017.html Content-length: 406 Date: Wed, 01 Mar 2000 15:55:21 +1100 From: Andrew Cagney Hello, I'd like to put forward the following: x86 target Mark Kettenis kettenis@gnu.org GNU/Linux/x86 native & host Jim Blandy jimb@cygnus.com Mark Kettenis kettenis@gnu.org No problems with those. I'll start working on those once you've added them to the MAINTAINERS file :-). Mark >From gzp@gzp.org.hu Wed Mar 01 18:21:00 2000 From: "Gabor Z. Papp" To: gdb@sourceware.cygnus.com Subject: gdb cvs Date: Wed, 01 Mar 2000 18:21:00 -0000 Message-id: <20000302032052.L17285@gzp.org.hu> References: <200003011940.e21Je9528423@mail.gzp.org.hu> X-SW-Source: 2000-03/msg00018.html Content-length: 110 | cvs checkout: authorization failed: server anoncvs.cygnus.com rejected access What is with the cvs access? >From ac131313@cygnus.com Wed Mar 01 19:56:00 2000 From: Andrew Cagney To: "Gabor Z. Papp" Cc: gdb@sourceware.cygnus.com Subject: Re: gdb cvs Date: Wed, 01 Mar 2000 19:56:00 -0000 Message-id: <38BDE5F9.49AD7232@cygnus.com> References: <200003011940.e21Je9528423@mail.gzp.org.hu> <20000302032052.L17285@gzp.org.hu> X-SW-Source: 2000-03/msg00019.html Content-length: 324 "Gabor Z. Papp" wrote: > > | cvs checkout: authorization failed: server anoncvs.cygnus.com rejected access > > What is with the cvs access? Same problem as the BINUTILS repository - it's been moved. Both GDB and BINUTILS are drawn from a common CVS repository. Check http://sourceware.cygnus.com/gdb/ enjoy, Andrew >From gzp@gzp.org.hu Wed Mar 01 19:59:00 2000 From: "Gabor Z. Papp" To: Andrew Cagney Cc: gdb@sourceware.cygnus.com Subject: Re: gdb cvs Date: Wed, 01 Mar 2000 19:59:00 -0000 Message-id: <20000302045932.A14600@gzp.org.hu> References: <200003011940.e21Je9528423@mail.gzp.org.hu> <20000302032052.L17285@gzp.org.hu> <38BDE5F9.49AD7232@cygnus.com> X-SW-Source: 2000-03/msg00020.html Content-length: 322 Andrew Cagney wrote: | > What is with the cvs access? | | Same problem as the BINUTILS repository - it's been moved. Both GDB and | BINUTILS are drawn from a common CVS repository. Thanks, now works fine. Only this /cvs/src isn't good, at least here. Both binutils and gdb updated to src/ instead of gdf/ or binutils/ >From kingdon@redhat.com Wed Mar 01 20:13:00 2000 From: Jim Kingdon To: Mark Mitchell Cc: gdb@sourceware.cygnus.com Subject: Re: Regressions problem (200 failures) Date: Wed, 01 Mar 2000 20:13:00 -0000 Message-id: References: <20000301123337B.mitchell@codesourcery.com> X-SW-Source: 2000-03/msg00021.html Content-length: 419 > I think GCC shouldn't put out any line notes for the prologue in the > first place. That's what's causing the problem, indirectly. Does GDB > require a line note in the prologue, or can we wait until the first > bit of real code? GDB expects the first line number to be for the real code (unless something has changed, or I'm remembering it wrong or something - I didn't actually play around with the test cases). >From kingdon@redhat.com Wed Mar 01 20:34:00 2000 From: Jim Kingdon To: Andrew Cagney Cc: GDB Discussion Subject: Re: [MAINT/RFC] Start devolving maintenance responsibility Date: Wed, 01 Mar 2000 20:34:00 -0000 Message-id: References: <38BC81A0.17D25C8@cygnus.com> X-SW-Source: 2000-03/msg00022.html Content-length: 1449 > Individuals who make changes to the debugger need approval from all > relevant domain maintainers before those changed can be checked in. Are you saying that making a change across a large number of files requires a dozen or so people to sign off on it? While I (probably) don't have a problem with that when something substantive and pervasive is being redesigned, it seems like it would be a mistake to take that attitude with respect to stylistic changes and cleaning up lint and the like. And I'm thinking that people with blanket write privs should be capable of figuring out which is which (or else they wouldn't have blanket write privs). I guess part of what I'm getting at is that I don't want to go down the dead end we did with CVS, in which we (well, I, although I had at least the acquiescence of others) tried to write up a lot of formal policies and procedures and such. Instead, the key is a set of maintainers who respect each other's expertise and willingness to work together. Some basic level of rules/guidelines is helpful, but I wonder whether concepts and words like "devolve", "maintenance domain", and "responsibility" are going too far. Or (to ask another way), what is the problem with the status quo? If it is that the paragraph about first and second maintainers goes too far in telling first maintainers how to relate to their second maintainers, let's fuzz it up rather than trying to spell things out more. >From ac131313@cygnus.com Wed Mar 01 21:00:00 2000 From: Andrew Cagney To: GDB Discussion Cc: GDB Patches Subject: [MAINT] Peter Schauer and Michael Snyder for ``Blanket Write'' maintainers Date: Wed, 01 Mar 2000 21:00:00 -0000 Message-id: <38BDF545.34DB6172@cygnus.com> X-SW-Source: 2000-03/msg00023.html Content-length: 454 Hello, I'd like to put forward that both: Michael Snyder msnyder@cygnus.com Peter Schauer Peter.Schauer@regent.e-technik.tu-muenchen.de be added to the ``Blanket Write Privs'' maintainers list. Michael Snyder has been hacking continuously on GDB since at least '96 and stands as Red Hat's most experienced GDB developer. In Peter Shauer, case he has been working on improving GDB for much longer (the early '90). Andrew >From mark@codesourcery.com Wed Mar 01 21:26:00 2000 From: Mark Mitchell To: kingdon@redhat.com Cc: donnte@microsoft.com, gdb@sourceware.cygnus.com Subject: Re: Regressions problem (200 failures) Date: Wed, 01 Mar 2000 21:26:00 -0000 Message-id: <20000301213331A.mitchell@codesourcery.com> References: <20000301123337B.mitchell@codesourcery.com> X-SW-Source: 2000-03/msg00024.html Content-length: 718 >>>>> "Jim" == Jim Kingdon writes: >> I think GCC shouldn't put out any line notes for the prologue >> in the first place. That's what's causing the problem, >> indirectly. Does GDB require a line note in the prologue, or >> can we wait until the first bit of real code? Jim> GDB expects the first line number to be for the real code Jim> (unless something has changed, or I'm remembering it wrong or Jim> something - I didn't actually play around with the test Jim> cases). Good, that means that the bug is in GCC -- even before my changes. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com >From ac131313@cygnus.com Wed Mar 01 23:15:00 2000 From: Andrew Cagney To: Jim Kingdon Cc: GDB Discussion Subject: Re: [MAINT/RFC] Start devolving maintenance responsibility Date: Wed, 01 Mar 2000 23:15:00 -0000 Message-id: <38BE146B.46ED6E4D@cygnus.com> References: <38BC81A0.17D25C8@cygnus.com> X-SW-Source: 2000-03/msg00025.html Content-length: 2686 Jim Kingdon wrote: [A response, I sometimes think this is being proposed in a vacume. Thanks!] > > Individuals who make changes to the debugger need approval from all > > relevant domain maintainers before those changed can be checked in. > Are you saying that making a change across a large number of files > requires a dozen or so people to sign off on it? While I (probably) > don't have a problem with that when something substantive and > pervasive is being redesigned, it seems like it would be a mistake to > take that attitude with respect to stylistic changes and cleaning up > lint and the like. And I'm thinking that people with blanket write > privs should be capable of figuring out which is which (or else they > wouldn't have blanket write privs). Some how, I'd expect common sense to prevail. With a stylistic change (ISO-C'ism, -W...), I would not expect it to be attempted in a single hit. I'd instead expect: o basic consensus by the maintainers on the move o individuals (blanket maintainers or other) to _incrementally_ work through the sources. At each stage a heads up before hand so that the group knows whats about to hit them :-) As an asside, I think I've so far used so called blanket check-ins privs to: o -> "gdb_wait.h" o fixing a #include in arm-tdep.c the first was agreed on months ago and the second was so small to be in the noise. > I guess part of what I'm getting at is that I don't want to go down > the dead end we did with CVS, in which we (well, I, although I had at > least the acquiescence of others) tried to write up a lot of formal > policies and procedures and such. Instead, the key is a set of > maintainers who respect each other's expertise and willingness to work > together. Some basic level of rules/guidelines is helpful, but I > wonder whether concepts and words like "devolve", "maintenance > domain", and "responsibility" are going too far. Sorry, devolve, as a word, is probably more meaningful to people from Commonwealth countries. > Or (to ask another way), what is the problem with the status quo? If > it is that the paragraph about first and second maintainers goes too > far in telling first maintainers how to relate to their second > maintainers, let's fuzz it up rather than trying to spell things out > more. Perhaphs that can be done that way. The wording was probably lousy. The underlying concern I have isn't with people like you that have been hacking on open code for years, its with people familar with GDB but not so familar with open source. For that reason, I think it is useful to spell out, in basic terms, how the system should work. thanks, Andrew >From eliz@delorie.com Thu Mar 02 02:08:00 2000 From: Eli Zaretskii To: kingdon@redhat.com Cc: gdb@sourceware.cygnus.com Subject: Re: Dependence on config.status Date: Thu, 02 Mar 2000 02:08:00 -0000 Message-id: <200003021007.FAA04124@indy.delorie.com> References: <200002280657.BAA27090@indy.delorie.com> <38BCCA84.74A4143E@cygnus.com> X-SW-Source: 2000-03/msg00026.html Content-length: 271 > Well, if memory serves, if you re-ran configure in such a way that > tm.h started linking to a different file, then the config.status > dependency was the only way to force a rebuild. How about adding some #define to config.h that would also change when this happens? >From Peter.Schauer@regent.e-technik.tu-muenchen.de Thu Mar 02 02:11:00 2000 From: "Peter.Schauer" To: kingdon@redhat.com (Jim Kingdon) Cc: mark@codesourcery.com, donnte@microsoft.com, gdb@sourceware.cygnus.com Subject: Re: Regressions problem (200 failures) Date: Thu, 02 Mar 2000 02:11:00 -0000 Message-id: <200003021010.LAA13693@reisser.regent.e-technik.tu-muenchen.de> References: X-SW-Source: 2000-03/msg00027.html Content-length: 850 > > I think GCC shouldn't put out any line notes for the prologue in the > > first place. That's what's causing the problem, indirectly. Does GDB > > require a line note in the prologue, or can we wait until the first > > bit of real code? > > GDB expects the first line number to be for the real code (unless > something has changed, or I'm remembering it wrong or something - I > didn't actually play around with the test cases). In case it isn't obvious: What is `real code' ? The initialization of local variables, is it considered part of the prologue or real code ? For practical debugging purposes (especially C++), the line number information (and thus the breakpoint) has to be put before the initialization code for local variables, so that we can debug object initialization. -- Peter Schauer pes@regent.e-technik.tu-muenchen.de >From mark@codesourcery.com Thu Mar 02 02:27:00 2000 From: Mark Mitchell To: Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE Cc: kingdon@redhat.com, donnte@microsoft.com, gdb@sourceware.cygnus.com Subject: Re: Regressions problem (200 failures) Date: Thu, 02 Mar 2000 02:27:00 -0000 Message-id: <20000302023420H.mitchell@codesourcery.com> References: <200003021010.LAA13693@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-03/msg00028.html Content-length: 762 >>>>> "Peter" == Peter Schauer writes: 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. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com >From Peter.Schauer@regent.e-technik.tu-muenchen.de Thu Mar 02 03:43: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: Thu, 02 Mar 2000 03:43:00 -0000 Message-id: <200003021143.MAA14294@reisser.regent.e-technik.tu-muenchen.de> References: <20000302023420H.mitchell@codesourcery.com> X-SW-Source: 2000-03/msg00029.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 muller@cerbere.u-strasbg.fr Thu Mar 02 03:55:00 2000 From: Pierre Muller To: "Peter.Schauer" Cc: gdb@sourceware.cygnus.com Subject: Re: Regressions problem (200 failures) Date: Thu, 02 Mar 2000 03:55:00 -0000 Message-id: <200003021206.NAA32271@cerbere.u-strasbg.fr> References: <20000302023420H.mitchell@codesourcery.com> X-SW-Source: 2000-03/msg00030.html Content-length: 1618 At 12:43 02/03/00 +0100, Peter.Schauer wrote: >> 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. I don't agree here ! If your breakpoint stop on the open brace (or the begin statement for the pascal extension I want to submit) you get the choice to use either: "Step" if you want to debug the function initialization code or "Next" if you don't want to ! That's really just a matter of taste... but if the function breakpoint is only set after the hidden initialization it will get very difficult to debug that code (you will not be able to set an explicit breakpoint there !) 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 muller@cerbere.u-strasbg.fr Thu Mar 02 04:43:00 2000 From: Pierre Muller To: gdb@sourceware.cygnus.com Subject: Indent -gnu ? Date: Thu, 02 Mar 2000 04:43:00 -0000 Message-id: <200003021257.NAA00259@cerbere.u-strasbg.fr> X-SW-Source: 2000-03/msg00031.html Content-length: 705 I want to format my PATCH for pascal extension before submitting it so I read that I should use GNU indent with -gnu option ! But I tried this on c-lang.h just to see and the result is that the current header file does not conform to indent output ! So my question is simply should I run indent on my files or should I send them without ! 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 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 Thu Mar 02 04:46:00 2000 From: Mark Kettenis To: mark@codesourcery.com Cc: Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE, kingdon@redhat.com, donnte@microsoft.com, gdb@sourceware.cygnus.com Subject: Re: Regressions problem (200 failures) Date: Thu, 02 Mar 2000 04:46:00 -0000 Message-id: <200003021246.e22CkWL00549@delius.kettenis.local> References: <200003021010.LAA13693@reisser.regent.e-technik.tu-muenchen.de> <20000302023420H.mitchell@codesourcery.com> X-SW-Source: 2000-03/msg00032.html Content-length: 1704 From: Mark Mitchell Date: Thu, 02 Mar 2000 02:34:20 -0800 >>>>> "Peter" == Peter Schauer writes: 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. The following might be relevant for this discussion: The comment on symtab.c:find_function_start_sal() says: /* Given a function symbol SYM, find the symtab and line for the start of the function. If the argument FUNFIRSTLINE is nonzero, we want the first line of real code inside the function. */ If you look at the implementation of find_function_start_sal() you'll see that it uses SKIP_PROLOGUE to skip over the function prologue if FUNFIRSTLINE is nonzero, and then chooses the next line after the prologue. So GDB shouldn't have any problems with line notes for the prologue. The implementation of SKIP_PROLOGUE for the i386 lives in i386-tdep.c:i386_skip_prologue(). According to the ChangeLog, this code has not been changed since early 1994 (Hi Peter!), and it is not unlikely that it has suffered some bit rot since then. Are the prologue's generated by GCC any different from those generated back in 1994? Mark >From Peter.Schauer@regent.e-technik.tu-muenchen.de Thu Mar 02 05:22:00 2000 From: "Peter.Schauer" To: kettenis@wins.uva.nl (Mark Kettenis) Cc: gdb@sourceware.cygnus.com Subject: Re: Regressions problem (200 failures) Date: Thu, 02 Mar 2000 05:22:00 -0000 Message-id: <200003021322.OAA14220@reisser.regent.e-technik.tu-muenchen.de> References: <200003021246.e22CkWL00549@delius.kettenis.local> X-SW-Source: 2000-03/msg00034.html Content-length: 1423 > The following might be relevant for this discussion: > > The comment on symtab.c:find_function_start_sal() says: > > /* Given a function symbol SYM, find the symtab and line for the start > of the function. > If the argument FUNFIRSTLINE is nonzero, we want the first line > of real code inside the function. */ > > If you look at the implementation of find_function_start_sal() you'll > see that it uses SKIP_PROLOGUE to skip over the function prologue if > FUNFIRSTLINE is nonzero, and then chooses the next line after the > prologue. So GDB shouldn't have any problems with line notes for the > prologue. SKIP_PROLOGUE is very machine dependent and sometimes you can't get it right (especially with optimization and instruction reordering). If GDB's prologue skipping stops to early, then we are at the mercy of GCC to provide us with the `correct' line note, and additional line notes in the prologue will confuse GDB under these circumstances. And if GCC puts a line note at the first instruction after the prologue, and marks it with the line number of the opening brace, then GDB will stop at the opening brace, which I would like to avoid at all cost, because I find it confusing. So there are actually two questions: At which instruction should GCC put the first line note and which source line number should be associated with the note. -- Peter Schauer pes@regent.e-technik.tu-muenchen.de >From kettenis@wins.uva.nl Thu Mar 02 05:22:00 2000 From: Mark Kettenis To: muller@cerbere.u-strasbg.fr Cc: gdb@sourceware.cygnus.com Subject: Re: Indent -gnu ? Date: Thu, 02 Mar 2000 05:22:00 -0000 Message-id: <200003021321.e22DLrF00601@delius.kettenis.local> References: <200003021257.NAA00259@cerbere.u-strasbg.fr> X-SW-Source: 2000-03/msg00033.html Content-length: 1236 Date: Thu, 02 Mar 2000 13:41:58 +0100 From: Pierre Muller I want to format my PATCH for pascal extension before submitting it so I read that I should use GNU indent with -gnu option ! Hi Pierre, I do hope that you'll break your patch up in some smaller chunks. IMHO the fact that you sent it as a large chunk, was one of the main reasons why it was ignored last fall. But I tried this on c-lang.h just to see and the result is that the current header file does not conform to indent output ! Looks like you're using a different `indent' than was used on the GDB sources. I think, this shows that defining the GDB coding standards in terms of the output of `indent' is not really workable. I've also noticed that `indent' sometime really messes up the output, because it gets confused by certain constructs. So my question is simply should I run indent on my files or should I send them without ! I'd say that avoiding gratuitous reformatting is more important than running your changes through `indent'. Thus, make sure that your patches only contains changes for code you really changed, and that these changes correspond to the GNU coding standards. Mark >From muller@cerbere.u-strasbg.fr Thu Mar 02 05:33:00 2000 From: Pierre Muller To: Mark Kettenis Cc: gdb@sourceware.cygnus.com Subject: Pascal language support patch preparation Date: Thu, 02 Mar 2000 05:33:00 -0000 Message-id: <200003021347.OAA01051@cerbere.u-strasbg.fr> References: <200003021257.NAA00259@cerbere.u-strasbg.fr> X-SW-Source: 2000-03/msg00035.html Content-length: 2092 At 14:21 02/03/00 +0100, you wrote: > Date: Thu, 02 Mar 2000 13:41:58 +0100 > From: Pierre Muller > > I want to format my PATCH for pascal extension before submitting it > so I read that I should use GNU indent with -gnu option ! > >Hi Pierre, I do hope that you'll break your patch up in some smaller >chunks. IMHO the fact that you sent it as a large chunk, was one of >the main reasons why it was ignored last fall. But adding a new language means at least : new files : p-lang.h p-lang.c p-valprint.c p-typeprint.c and p-exp.y plus the changes needed to make GDB know about pascal language ! This means a bunch of other changes of course ! > But I tried this on c-lang.h just to see > and the result is that the current header file does not conform to > indent output ! > >Looks like you're using a different `indent' than was used on the GDB >sources. I think, this shows that defining the GDB coding standards >in terms of the output of `indent' is not really workable. I've also >noticed that `indent' sometime really messes up the output, because it >gets confused by certain constructs. indent --version gives "GNU indent 2.2.5" is that not the current version ?? > So my question is simply should I run indent on my files > or should I send them without ! > >I'd say that avoiding gratuitous reformatting is more important than >running your changes through `indent'. Thus, make sure that your >patches only contains changes for code you really changed, and that >these changes correspond to the GNU coding standards. One of the main problem is that my patches are primarily files c-*.* first copied to p-*.* then adapted to reflect pascal instead of C, but of course this copy was primarily done on v4.17 ! I change after so that it compiled with v4.18, but all the changes made in c-*.* since then are not in my pascal files. 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 Thu Mar 02 06:06:00 2000 From: Mark Kettenis To: muller@cerbere.u-strasbg.fr Cc: gdb@sourceware.cygnus.com Subject: Re: Pascal language support patch preparation Date: Thu, 02 Mar 2000 06:06:00 -0000 Message-id: <200003021406.e22E6Rm00677@delius.kettenis.local> References: <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> X-SW-Source: 2000-03/msg00036.html Content-length: 3028 X-Sender: muller@ics.u-strasbg.fr Date: Thu, 02 Mar 2000 14:32:02 +0100 From: Pierre Muller Cc: gdb@sourceware.cygnus.com Content-Type: text/plain; charset="us-ascii" At 14:21 02/03/00 +0100, you wrote: > Date: Thu, 02 Mar 2000 13:41:58 +0100 > From: Pierre Muller > > I want to format my PATCH for pascal extension before submitting it > so I read that I should use GNU indent with -gnu option ! > >Hi Pierre, I do hope that you'll break your patch up in some smaller >chunks. IMHO the fact that you sent it as a large chunk, was one of >the main reasons why it was ignored last fall. But adding a new language means at least : new files : p-lang.h p-lang.c p-valprint.c p-typeprint.c and p-exp.y plus the changes needed to make GDB know about pascal language ! This means a bunch of other changes of course ! Patches to create those new p-* files cannot be broken up of course, but your patch also touches a lot of the other GDB files. Breaking those patches up in smaller though functionally related chunks makes reviewing and applying the patches a lot easier. I'd advise you to do the following: 1. If you need some tweaks in GDB that do not depend on the Pascal support itself, start submitting these ASAP. 2. Then send the new p-* as one single patch. 3. Then send a patch that adds the code to hook in the GDB support. > But I tried this on c-lang.h just to see > and the result is that the current header file does not conform to > indent output ! > >Looks like you're using a different `indent' than was used on the GDB >sources. I think, this shows that defining the GDB coding standards >in terms of the output of `indent' is not really workable. I've also >noticed that `indent' sometime really messes up the output, because it >gets confused by certain constructs. indent --version gives "GNU indent 2.2.5" is that not the current version ?? Yes it is, but it isn't the version that was used for reformatting the GDB sources. See: http://sourceware.cygnus.com/ml/gdb/1999-q3/msg00014.html for more information. > So my question is simply should I run indent on my files > or should I send them without ! > >I'd say that avoiding gratuitous reformatting is more important than >running your changes through `indent'. Thus, make sure that your >patches only contains changes for code you really changed, and that >these changes correspond to the GNU coding standards. One of the main problem is that my patches are primarily files c-*.* first copied to p-*.* then adapted to reflect pascal instead of C, but of course this copy was primarily done on v4.17 ! I change after so that it compiled with v4.18, but all the changes made in c-*.* since then are not in my pascal files. The best thing would probably be to port these changes over to the p-*.* files. Mark >From muller@cerbere.u-strasbg.fr Thu Mar 02 06:17:00 2000 From: Pierre Muller To: Mark Kettenis Cc: gdb@sourceware.cygnus.com Subject: Re: Pascal language support patch preparation Date: Thu, 02 Mar 2000 06:17:00 -0000 Message-id: <200003021432.PAA01976@cerbere.u-strasbg.fr> References: <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> X-SW-Source: 2000-03/msg00037.html Content-length: 4046 At 15:06 02/03/00 +0100, you wrote: > X-Sender: muller@ics.u-strasbg.fr > Date: Thu, 02 Mar 2000 14:32:02 +0100 > From: Pierre Muller > Cc: gdb@sourceware.cygnus.com > Content-Type: text/plain; charset="us-ascii" > > At 14:21 02/03/00 +0100, you wrote: > > Date: Thu, 02 Mar 2000 13:41:58 +0100 > > From: Pierre Muller > > > > I want to format my PATCH for pascal extension before submitting it > > so I read that I should use GNU indent with -gnu option ! > > > >Hi Pierre, I do hope that you'll break your patch up in some smaller > >chunks. IMHO the fact that you sent it as a large chunk, was one of > >the main reasons why it was ignored last fall. > > But adding a new language means at least : > new files : > p-lang.h p-lang.c p-valprint.c p-typeprint.c and p-exp.y > plus the changes needed to make GDB know about pascal language ! > This means a bunch of other changes of course ! > >Patches to create those new p-* files cannot be broken up of course, >but your patch also touches a lot of the other GDB files. Breaking >those patches up in smaller though functionally related chunks makes >reviewing and applying the patches a lot easier. > >I'd advise you to do the following: > >1. If you need some tweaks in GDB that do not depend on the Pascal > support itself, start submitting these ASAP. I don't think I really have such code ! >2. Then send the new p-* as one single patch. Alone ? tihs would just leave them unused first ! >3. Then send a patch that adds the code to hook in the GDB support. OK, here a would have the biggest part of the problems probably because some of the change are not trivial but I agree that I can probably splitt those. For instance a big problem on which I spent a lot of time is to get GDB to accept the fact the pascal is case insensitive this required changes in gnu-regex code !! > > But I tried this on c-lang.h just to see > > and the result is that the current header file does not conform to > > indent output ! > > > >Looks like you're using a different `indent' than was used on the GDB > >sources. I think, this shows that defining the GDB coding standards > >in terms of the output of `indent' is not really workable. I've also > >noticed that `indent' sometime really messes up the output, because it > >gets confused by certain constructs. > > indent --version gives "GNU indent 2.2.5" > is that not the current version ?? > >Yes it is, but it isn't the version that was used for reformatting the >GDB sources. See: > > http://sourceware.cygnus.com/ml/gdb/1999-q3/msg00014.html This not really very informative on the method that was used to do it ! >for more information. > > > So my question is simply should I run indent on my files > > or should I send them without ! > > > >I'd say that avoiding gratuitous reformatting is more important than > >running your changes through `indent'. Thus, make sure that your > >patches only contains changes for code you really changed, and that > >these changes correspond to the GNU coding standards. > > One of the main problem is that my patches are primarily files > c-*.* first copied to p-*.* then adapted to reflect pascal instead > of C, but of course this copy was primarily done on v4.17 ! I > change after so that it compiled with v4.18, but all the changes > made in c-*.* since then are not in my pascal files. > >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 :( 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 muller@cerbere.u-strasbg.fr Thu Mar 02 06:38:00 2000 From: Pierre Muller To: Mark Kettenis Cc: gdb@sourceware.cygnus.com Subject: Re: Pascal language support patch preparation Date: Thu, 02 Mar 2000 06:38: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-03/msg00038.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 kingdon@redhat.com Thu Mar 02 06:46:00 2000 From: Jim Kingdon To: ac131313@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: [MAINT/RFC] Start devolving maintenance responsibility Date: Thu, 02 Mar 2000 06:46:00 -0000 Message-id: <200003021446.JAA31093@devserv.devel.redhat.com> References: <38BC81A0.17D25C8@cygnus.com> <38BE146B.46ED6E4D@cygnus.com> X-SW-Source: 2000-03/msg00039.html Content-length: 1325 > Sorry, devolve, as a word, is probably more meaningful to people from > Commonwealth countries. I'm familiar with the word (e.g. Scotland) but at least for me it has all these connotations of national sovereignty and power and such. For example, it is a dead end to assume that an OS vendor should automatically maintain GDB on that OS because they "own" the platform or something. > The underlying concern I have isn't with people like you that have been > hacking on open code for years, its with people familar with GDB but not > so familar with open source. For that reason, I think it is useful to > spell out, in basic terms, how the system should work. Maybe link to The Cathedral and the Bazaar (which is well known) and Alan Cox's Town Council paper (which deserves to be better known and is at http://slashdot.org/features/98/10/13/1423253.shtml )? I was just showing the Town Council paper to someone in a GDB context and it seemed to resonate. I'm sure the looseness of this approach will make some people nervous. But you can't build trust through rules and policies either. What is going to turn GDB development into the (more) vibrant community we want it to be is delivering on the promises to add maintainers and otherwise open up. We've made great progress in the last month and let's keep it up. >From ac131313@cygnus.com Thu Mar 02 06:47:00 2000 From: Andrew Cagney To: Pierre Muller Cc: Mark Kettenis , gdb@sourceware.cygnus.com Subject: Re: Pascal language support patch preparation Date: Thu, 02 Mar 2000 06:47:00 -0000 Message-id: <38BE7E80.4DA49303@cygnus.com> References: <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003021452.PAA02334@cerbere.u-strasbg.fr> X-SW-Source: 2000-03/msg00040.html Content-length: 902 Pierre Muller wrote: > > >>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! Try putting copies of the old and the new file through the same indentation program and then comparing them. It will flush out the indentation changes leaving you with just code changes. enjoy, Andrew >From eliz@delorie.com Thu Mar 02 06:51:00 2000 From: Eli Zaretskii To: Pierre Muller Cc: Mark Kettenis , gdb@sourceware.cygnus.com Subject: Re: Pascal language support patch preparation Date: Thu, 02 Mar 2000 06:51:00 -0000 Message-id: <200003021451.JAA05553@indy.delorie.com> References: <200003021452.PAA02334@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> X-SW-Source: 2000-03/msg00041.html Content-length: 431 > the diffs are mainly due to the reformating thus it is very difficult to > find out where the code really did change!! Use "diff -cbBw", and you will see mostly real code changes. But do NOT send diffs generated by "diff -cbBw", as they will most probably fail to apply. Instead, after you have seen what/where are the real code changes, and copied them to the p-*.* files, make the diffs with the normal "diff -c" command. >From kettenis@wins.uva.nl Thu Mar 02 07:02:00 2000 From: Mark Kettenis To: muller@cerbere.u-strasbg.fr Cc: gdb@sourceware.cygnus.com Subject: Re: Pascal language support patch preparation Date: Thu, 02 Mar 2000 07:02:00 -0000 Message-id: <200003021502.e22F2fk07660@delius.kettenis.local> References: <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003021432.PAA01976@cerbere.u-strasbg.fr> X-SW-Source: 2000-03/msg00042.html Content-length: 2650 Date: Thu, 02 Mar 2000 15:16:19 +0100 From: Pierre Muller >Patches to create those new p-* files cannot be broken up of course, >but your patch also touches a lot of the other GDB files. Breaking >those patches up in smaller though functionally related chunks makes >reviewing and applying the patches a lot easier. > >I'd advise you to do the following: > >1. If you need some tweaks in GDB that do not depend on the Pascal > support itself, start submitting these ASAP. I don't think I really have such code ! Are you sure? The patch I downloaded last fall includes changes to breakpoint.c, findvar.c, i387-tdep.c, infcmd.c and source.c that seem to be pretty independent of Pascal at first glance. >2. Then send the new p-* as one single patch. Alone ? tihs would just leave them unused first ! That's not a problem. The point is that these changes cannot break anything, so they don't need a lot of attention. >3. Then send a patch that adds the code to hook in the GDB support. OK, here a would have the biggest part of the problems probably because some of the change are not trivial but I agree that I can probably splitt those. That would indeed be best, since that lets the maintainer of that particular part of GDB deal with problems one at a time, which in general gets the changes integrated much quicker. For instance a big problem on which I spent a lot of time is to get GDB to accept the fact the pascal is case insensitive this required changes in gnu-regex code !! I'm sorry to hear that you spent a lot of time on it. Modifying the regex code is something that we should only do as a last resort since it is shared with a lot of other GNU packages. Maybe GDB should use the POSIX functions instead of the BSD functions such that REG_ICASE can be used when the default language is Pascal. On the bright side: Case insensitivity would be convenient, but should not be essential for basic Pascal support in GDB. We should be able to address this as a seperate issue. I'll see what I can do. For now it is probably better to leave out this bit when you send your new patches. > indent --version gives "GNU indent 2.2.5" > is that not the current version ?? > >Yes it is, but it isn't the version that was used for reformatting the >GDB sources. See: > > http://sourceware.cygnus.com/ml/gdb/1999-q3/msg00014.html This not really very informative on the method that was used to do it ! Pardon me? It clearly states that: ``[Stan] used indent 1.9.1 (with no arguments)''. Mark >From kettenis@wins.uva.nl Thu Mar 02 07:08:00 2000 From: Mark Kettenis To: muller@cerbere.u-strasbg.fr Cc: gdb@sourceware.cygnus.com Subject: Re: Pascal language support patch preparation Date: Thu, 02 Mar 2000 07:08:00 -0000 Message-id: <200003021508.e22F8og07862@delius.kettenis.local> References: <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003021452.PAA02334@cerbere.u-strasbg.fr> X-SW-Source: 2000-03/msg00043.html Content-length: 521 Date: Thu, 02 Mar 2000 15:36:54 +0100 From: Pierre Muller The logs are also useless as most only are weekly imports from the workers CVS before the CVS was made public! Looks like we need to teach you the concept of ChangeLogs :-). Take a look at the files named ChangeLog* in the GDB source directory of your checked out sources. They list all the changes made to the sources over the years. Preferably you would include ChangeLog entries with you patches too. Mark >From muller@cerbere.u-strasbg.fr Thu Mar 02 07:59:00 2000 From: Pierre Muller To: Mark Kettenis Cc: gdb@sourceware.cygnus.com Subject: Re: Pascal language support patch preparation Date: Thu, 02 Mar 2000 07:59:00 -0000 Message-id: <200003021613.RAA03663@cerbere.u-strasbg.fr> References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> X-SW-Source: 2000-03/msg00044.html Content-length: 3955 At 16:02 02/03/00 +0100, you wrote: > Date: Thu, 02 Mar 2000 15:16:19 +0100 > From: Pierre Muller > > >Patches to create those new p-* files cannot be broken up of course, > >but your patch also touches a lot of the other GDB files. Breaking > >those patches up in smaller though functionally related chunks makes > >reviewing and applying the patches a lot easier. > > > >I'd advise you to do the following: > > > >1. If you need some tweaks in GDB that do not depend on the Pascal > > support itself, start submitting these ASAP. > > I don't think I really have such code ! > >Are you sure? The patch I downloaded last fall includes changes to >breakpoint.c, findvar.c, i387-tdep.c, infcmd.c and source.c that seem >to be pretty independent of Pascal at first glance. Most are obsolete now ! > >2. Then send the new p-* as one single patch. > > Alone ? tihs would just leave them unused first ! > >That's not a problem. The point is that these changes cannot break >anything, so they don't need a lot of attention. > > >3. Then send a patch that adds the code to hook in the GDB support. > > OK, here a would have the biggest part of the problems probably > because some of the change are not trivial but I agree that I can probably > splitt those. > >That would indeed be best, since that lets the maintainer of that >particular part of GDB deal with problems one at a time, which in >general gets the changes integrated much quicker. > This reminds me that I have one other patch which is quite smaller but that is limited to DJGPP target for now. It allows to read memory from another selector this was very usefull 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!! > For instance a big problem on which I spent a lot of time is to > get GDB to accept the fact the pascal is case insensitive > this required changes in gnu-regex code !! > >I'm sorry to hear that you spent a lot of time on it. Modifying the >regex code is something that we should only do as a last resort since >it is shared with a lot of other GNU packages. Maybe GDB should use >the POSIX functions instead of the BSD functions such that REG_ICASE >can be used when the default language is Pascal. I would also prefer a simpler approach because that code is quite ugly in my opinion! >On the bright side: Case insensitivity would be convenient, but should >not be essential for basic Pascal support in GDB. We should be able >to address this as a seperate issue. I'll see what I can do. For now >it is probably better to leave out this bit when you send your new >patches. Anyhow I agree that this can and should be done later. > >Yes it is, but it isn't the version that was used for reformatting the > >GDB sources. See: > > > > http://sourceware.cygnus.com/ml/gdb/1999-q3/msg00014.html > > This not really very informative on the method that was used to do it ! > >Pardon me? It clearly states that: ``[Stan] used indent 1.9.1 (with >no arguments)''. Sorry, I didn't read the message carefully enough it seems :( 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 broeker@physik.rwth-aachen.de Thu Mar 02 08:00:00 2000 From: Hans-Bernhard Broeker To: gdb@sourceware.cygnus.com Cc: Eli Zaretskii Subject: Re: Regressions problem (200 failures) Date: Thu, 02 Mar 2000 08:00:00 -0000 Message-id: X-SW-Source: 2000-03/msg00045.html Content-length: 2592 This is an answer to < 20000301123337B.mitchell@codesourcery.com > [I've been pointed to this discussion by Eli Zaretskii, but I'm not on the gdb mailing list, myself. I just read through it on the WWW archive. So please, if you answer, Cc: to me, if possible. Thank you.] The point raised in this discussion has, by coincidence, caused a similar problem, with the DJGPP release version of GCC 2.95.2 and GDB 4.18. The problem is that for very short functions (one, maybe two lines of actual code, between the braces), gdb would not stop *at all* if you 'step' into a function from outside, because of badly positioned line number debug symbols. Looking at the assembly generated by GCC, it turned out that the problem lies in the way the function prologues and epilogues were written, compared to earlier GCC releases. So, to answer one of the questions raised in your discussion: to some extent, the prologue/epilogue have indeed changed, since 1994. The whole method of outputting prologues has been changed, since gcc-2.8.1, it seems, even though the typical set of machine operations has stayed the same, for this platform. Originally, prologues and epilogues were generated directly as assembly, by a specialized function, i.e. they were not subject to RTL transformations. Now, by default at least, they're generated as RTL, rather early in the compilation, and subject to modification along with the 'real code'. As to the question where the first line number label ought to be put, and what line it should point, I think the behaviour of previous GCC/GDB combinations was perfectly sane: the line number opcode is output right after the prologue, and it points to the line the next machine instruction originated from (initialization of an automatic variable, if present, an executable statement otherwise). Opposed to this expected behaviour, gcc-2.95.2 outputs a line note *before* the prologue (and one for the closing brace after the epilogue, instead of before it, as it used to be). By disabling the RTL-style prologue generating mechanism (undocumented GCC option -mno-schedule-prologue), you get back the traditional behaviour. Currently, the conclusion of discussion between me and Eli is that this constitutes a bug in gcc-2.95.2. Wether or not that's still present in the current snapshot remains to be checked. AFAICS, the GCC patch from Mark Mitchell that caused all this hassle for your GDB testsuite meant to fix that, but didn't work out as planned. Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Donn Terry To: "'gdb@sourceware.cygnus.com'" Cc: "'mark@codesourcery.com'" Subject: Regressions problem (200 failures) Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-ID: X-SW-Source: 2000-q1/msg00475.html Message-ID: <20000401000000.28gleBwuF35TA35PRyb0veXPIPohNjBsDli2VJCPXO0@z> Andrew has asked me to see if there are others affected by this... On 2/17, the following patch was made to gcc: > 2000-02-17 Mark Mitchell > > * function.c (thread_prologue_and_epilogue_insns): Put a line note > after the prologue. It has the effect, in my case at least, of causing gdb to break at the "{" of many functions when breaking at a function name (5 of 5 main()s that I tried, but not too many other functions). (Usually gdb breaks breaks at the first statement rather than somewhere in the function prologue). I discussed this with Mark Mitchell, and he concurs that that could be a side-effect of the patch (whose purpose is to assure that SOME breakpoint occurs at the beginning of each function). That, in itself, isn't a problem (except possibly with user perception). However, the gdb regressions are written in such a way that they expect to stop at the first statement (and often do a single "n", expecting the first statement to be executed). This causes well over 200 (mostly cascade) regression failures. Andrew asserts that the regressions aren't being too picky in this regard because of user expectation. The problem for me is I suspect that they're BOTH right, but there are regression failures unless something happens. Are there others out there who are seeing this (run the regressions pointing it at a new gcc)? (The gcc CVS as of 5:30 or so PST last night still exhibited the problem.) Does anyone have any thougts on how to proceed? Donn Terry Speaking, of course, only for myself. >From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000 From: Elena Zannoni To: Eli Zaretskii Cc: Pierre Muller , gdb@sourceware.cygnus.com, Elena Zannoni Subject: Re: Buffering problems with "gdb < foo" Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <14533.8241.716311.478074@kwikemart.cygnus.com> References: <200003070845.JAA27855@cerbere.u-strasbg.fr> <200003070851.DAA14463@indy.delorie.com> X-SW-Source: 2000-q1/msg00559.html Content-length: 3075 Eli Zaretskii writes: > > > dir needs no confirmation if not invoked from tty ! > > Did you actually look at the from_tty variable's value inside > dir_command? I don't have the GDB 5.0 binary here, but GDB certainly > *does* ask for confirmation if invoked with stdin and stdout > redirected, at least in the DJGPP version. Elena, is that a bug? > When I try this on solaris, in directory_command(), from_tty is 1, but the query() function is the one that finds out that it shouldn't ask the question to the user. int query (char *ctlstr,...) { va_list args; register int answer; register int ans2; int retval; va_start (args, ctlstr); if (query_hook) { return query_hook (ctlstr, args); } /* Automatically answer "yes" if input is not from a terminal. */ if (!input_from_terminal_p ()) return 1; [...] } This input_from_terminal_p() function does: int input_from_terminal_p () { return gdb_has_a_terminal () && (instream == stdin) & caution; } In my case the gdb_has_a_terminal() returns 0, so the query is not asked. All seems to work fine fro solaris. What happens on DJGPP? Is gdb_has_a terminal() returning 1, maybe? > Anyway, the basic point is still valid, even if this particular > example is not: when stdin is redirected to a file, GDB should turn > editing off. Or just assume that all the queries have yes as automatic answer, which is what I always thought it was doing. > > > I think its because y is not a valid GDB command ! > > Invalid commands don't cause GDB to exit, they just result in an error > message. It would be inconceivable to have GDB exit every time I > mistype a command ;-). Yes, the 'y''s are just generating errors. Here is what I get: kwikemart.cygnus.com: 9 % cat commands file testsuite/gdb.base/break dir y dir . break main run q y kwikemart.cygnus.com: 8 % ./gdb -nw -nx < commands GNU gdb 4.18.1 (UI_OUT) 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 "sparc-sun-solaris2.5.1". (gdb) file testsuite/gdb.base/break Reading symbols from testsuite/gdb.base/break...done. (gdb) dir Source directories searched: $cdir:$cwd (gdb) y Undefined command: "y". Try "help". (gdb) dir . Source directories searched: /kwikemart/homer/ezannoni/flathead-dev/solaris/gdb:$cdir:$cwd (gdb) break main Breakpoint 1 at 0x10824: file /kwikemart/marge/ezannoni/flathead-dev/devo/gdb/testsuite/gdb.base/break.c, line 75. (gdb) run Starting program: /kwikemart/homer/ezannoni/flathead-dev/solaris/gdb/testsuite/gdb.base/break Breakpoint 1, main (argc=1, argv=0xeffff124, envp=0xeffff12c) at /kwikemart/marge/ezannoni/flathead-dev/devo/gdb/testsuite/gdb.base/break.c:75 75 if (argc == 12345) { /* an unlikely value < 2^16, in case uninited */ (gdb) q Elena >From jtc@redback.com Sat Apr 01 00:00:00 2000 From: jtc@redback.com (J.T. Conklin) To: "H . J . Lu" Cc: Mark Kettenis , shebs@apple.com, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: A patch for gnu-regex Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <5mvh2yugpy.fsf@jtc.redbacknetworks.com> References: <20000307134103.A20533@valinux.com> <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com> <5mg0u2l3g0.fsf@jtc.redbacknetworks.com> <20000307162127.D485@lucon.org> <200003080044.e280iGB00429@delius.kettenis.local> <5m4saivyew.fsf@jtc.redbacknetworks.com> <20000307211842.C1573@lucon.org> X-SW-Source: 2000-q1/msg00589.html Content-length: 1401 >>>>> "hjl" == H J Lu writes: hjl> The current master copy of GNU regex is in glibc. I'd like to be hjl> able to compile gdb on a known good glibc base system using the hjl> GNU regex in glibc. The problem, as I see it, with linking with a host's regex library is that gdb does not know whether or not it is "good". We could write an autoconf test that attempts to verify the library, or some heuristic like __GLIBC__ && __GLIBC__ >= 2, but neither is as safe as using the known good version of the library that is bundled with GDB. One could argue that if we're worried about regex, why aren't we worried about a hundred other things and provide local copies of them. I'll concede that that would be silly, but I believe that historical problems with the regex code makes it a special case. Having said all that, I'm not opposed to using the host regex. I'd like to see us change the regex usage within GDB to use the POSIX.2 API so that we can link with any modern hosts library. But since the benefits are small and the risks large, I think it's not the type of change we want to be making while were trying to wrap up a release. hjl> I don't want to spend time to check if gdb has the updated regex hjl> or not. It doesn't matter much to me. It's a known good implementation that works well enough for GDB's purposes. --jtc -- J.T. Conklin RedBack Networks >From shebs@apple.com Sat Apr 01 00:00:00 2000 From: Stan Shebs To: Jim Kingdon Cc: gdb@sourceware.cygnus.com Subject: Re: Status Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A48875.B520ED34@apple.com> References: <38A34041.B443DAFB@apple.com> <38A46C5C.F8301644@apple.com> <200002112037.PAA02309@devserv.devel.redhat.com> X-SW-Source: 2000-q1/msg00233.html Content-length: 1623 Jim Kingdon wrote: > But I guess the GCC system makes sense to me. If something is enough > of an issue to be a "technical controversy" in the sense of something > people would escalate to the chief technical maintainer/team, you kind > of want to get people on board as much as possible. Because if you > proceed without _some_ level of consensus (not among the whole world, > but at least among a small group of people most involved), then it > creates various kinds of pain. > > I mean, there is almost always a way out (e.g. make it an option or > something, if there really a demand for both solutions). The hard part comes when somebody has to make a single choice. For instance, Linus has often had to make arbitrary decisions, in some cases without necessarily being the big PCMCIA-PS/2-bridge :-) expert. But in general people agree that his involvement has been better for Linux' continued evolution than not. Could a committee have done as well? Hard to say. > One thing I don't want to be single-string is the process of making > checkins which are believed to be relatively uncontroversial. Right > now there is a big problem when the person listed in MAINTAINERS for a > particular file gets busy or is on vacation or whatever. Or to put it > another way, being a maintainer should grant you the right to overrule > other people but it shouldn't grant you the right to stop things in > their tracks. Or something like that. Absolutely. I hope that every maintainer has sent in their login info and ssh keys and all, there should be no obstacle to them making their own commits now, right? Stan >From shebs@apple.com Sat Apr 01 00:00:00 2000 From: Stan Shebs To: Daniel Berlin Cc: gdb@sourceware.cygnus.com Subject: Re: Another Issue for 5.0 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38AC4EC7.E3F1EEDE@apple.com> References: X-SW-Source: 2000-q1/msg00332.html Content-length: 1054 Daniel Berlin wrote: > > IMHO, the overload resolution for DWARF2/STABS/all non-hp platforms should > really be fixed for 5.0. > I have patches to do this (in fact, i'm about to send another jumbo patch > to gdb-patches with it all combined so i don't have to keep emailing it to > people :P), with no regressions, well, actually, that's not true. > Some overload resolution things that were xfail before in the testsuite > now pass. > Sorry about that. I'll try to make sure i keep the broken things broken in > the future. :P :-) > But, anyway, i get about 5-10 emails a week asking for those patches. > Even on HP using aCC, where overload resolution works, you get benefits > because i added support for references in overloads, and fixed a problem > where the compares against function names were whitespace sensitive where > they shouldn't have been (so operator [] would be considered the same > function as operator[] when we were hunting down overloads). This all sounds great! Are there any obstacles to just installing the patches? Stan >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Mark Kettenis Cc: dan@cgsoftware.com, gdb@sourceware.cygnus.com Subject: Re: Odd, ptrace_getregs Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38CDE483.C09982B8@cygnus.com> References: <200003131833.TAA19979@landau.wins.uva.nl> X-SW-Source: 2000-q1/msg00693.html Content-length: 505 Mark Kettenis wrote: > I was silently hoping nobody would notice :-(. I corrected a typo in > configure.in, but forgot to run autoconf before checking it in. It's > basically harmless since it is only the printing of the value that's > broken. I just hoped that someone would find the need to regenerate > configure soon. Feel free to check in a regenerated autoconf. Have a look for the fateful phrase ``Fix typo.'' in the ChangeLogs :-) It should make you feel like you're not alone :-) Andrew >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Jason Molenda Cc: gdb-testers@sourceware.cygnus.com, 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: <389F6110.A54017D@cygnus.com> References: <389EC815.BC34F3E6@cygnus.com> <20000207112957.A27486@cygnus.com> X-SW-Source: 2000-q1/msg00140.html Content-length: 2240 Jason Molenda wrote: > > 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. I make an ambid claim, everyone else steps up to the table with their personal agenda, we all start to negotiate .... :-) > 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. Yes, more than anything else I should be interested build/test results. Thanks for reminding me :-) > On the other hand, I do agree that a release will go much more smoothly > now that the repository is on sourceware. Yes, turn around time once a patch is approved is going to tend to zero. Ya! Any way, you will have noticed that I've (for the first time ever?) given an approximate date for the major release that will follow 5.0. I've done it for two reasons: o to make it clear how quickly this release really should come out. o to make it clear that if something misses the 5.0 boat then 5.1 will be departing less than 6 months later. Given that this is a real departure from GDB's previous habits (1-2 year release cycles) I suspect I'm going to have difficulty convincing people - I can but try :-). I think of 5.0 as a consolidation of the significant amount of re-engineering that has gone on over the last year. For it I'm only going to be worried about major failures or serious losses of functionality. Enhancements are for 5.1. > MHO Always more than welcome :-) enjoy, Andrew >From hjl@lucon.org Sat Apr 01 00:00:00 2000 From: "H . J . Lu" To: GDB Subject: Does gdb support calling C++ member functions? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000114080427.A23281@lucon.org> X-SW-Source: 2000-q1/msg00032.html Content-length: 105 Does gdb support calling C++ member functions? I cannot get it to work. Any suggestions? Thanks. H.J. >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Paul Breed Cc: gdb@sourceware.cygnus.com Subject: Re: GDB/Coldfire bug Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38AA4E9A.87C39EFA@cygnus.com> References: <20000125215209.14490.qmail@web3501.mail.yahoo.com> X-SW-Source: 2000-q1/msg00306.html Content-length: 1451 Paul Breed wrote: > > I'm a bit lost on how to solve my GDB problem. > If this is the wrong newslist can you suggest the > proper one? > > I am trying to use GDB/Insite in a cross compiler > environment. I have a S/W GDB Stub running on the > Coldfire. It seems to work great. > > GDB seems to have some problems.... > c -> continue works. > s -> Step works. > break x -> works. > info locals works etc... > > n ->Step over does not work. It tries to read > things off the stack and gets confused. > > >From what research I've done online I believe this > problem is not really GDB, I believe it is a problem > with the debugging information generated by the > compiler. (gcc 2.95.2 configured for m68k-elf) Ah. m68k. One thing. I recently fixed a bug to do with m68k stack dumps - a back trace would fall off the end of the stack. Was this with the most recent version of GDB? Andrew Wed Dec 8 19:56:48 1999 Andrew Cagney * frame.h, blockframe.c: Rename default_frame_chain_valid to file_frame_chain_valid. Rename alternate_frame_chain_valid to func_frame_chain_valid. * config/sparc/tm-sparclite.h, config/mips/tm-mipsv4.h, config/m88k/tm-delta88v4.h, config/m68k/tm-m68kv4.h, config/m68k/tm-monitor.h, config/i386/tm-i386nw.h, config/i386/tm-i386v4.h, config/h8300/tm-h8300.h: Update. * mips-tdep.c (mips_gdbarch_init): Update. >From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: eliz@delorie.com Cc: gdb@sourceware.cygnus.com Subject: Re: i386_register_raw_size[] Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002232100.e1NL0nE00718@delius.kettenis.local> References: <200002231928.OAA18661@indy.delorie.com> X-SW-Source: 2000-q1/msg00387.html Content-length: 2799 Date: Wed, 23 Feb 2000 14:28:19 -0500 (EST) From: Eli Zaretskii i386-tdep.c defines the array used to compute REGISTER_RAW_SIZE thusly: /* i386_register_raw_size[i] is the number of bytes of storage in the actual machine representation for register i. */ int i386_register_raw_size[MAX_NUM_REGS] = { 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 10, 10, 10, 10, 10, 10, 10, 10, 4, 4, 4, 4, <<<<< 4, 4, 4, 4, <<<<< 16, 16, 16, 16, 16, 16, 16, 16, 4 }; The registers marked with "<<<<<" are the ones I want to discuss. These are control, status, and tag words, and the FP instruction address and operands. The ``raw'' part of the name and the comment imply that these should have the same size as they are saved by the low-level debug support functions on the target machine. I interpret that as the layout in memory of the data saved by FSAVE and similar instructions. I think ``raw'' implies that the data isn't yet interpreted by GDB yet, i.e. it is in the target byte order. However, the above definition of i386_register_raw_size[] does not follow the FPU state layout as saved by FSAVE. For example, the actual length of the control/status/tag words is 2 bytes, not 4, and the last register, the opcode occupies the 2 upper bytes of the same 4-byte word as the FP instruction selector. Messy ain't it? That, the fact that there exist other i386 instructions that use a different layout to store the same data, and the possibility of other OS'es that present the data ina very different layout, were the reasons to simply pretend that these are 32-bit registers. This was discussed in detail last fail. I believe the start of the thread is: http://sourceware.cygnus.com/ml/gdb/1999-q4/msg00033.html I don't have any problems to create an illusion in go32-nat.c that the FP register layout is like implied by i386_register_raw_size[], especially if it turns out that DJGPP is the only x86 target which doesn't already comply with this layout. But is this really the intent--to have all x86 targets use the same raw layout of registers, and if so, why do we need the corresponding virtual_size array and macros? Yes, that's what you are supposed to do! Look at i386gnu-nat.c and i386-linux-nat.c to see examples. It is really the intent to have the same layout on all x86 targets, since this makes it easier to use the same GDB for different x86 targets. The virtual_size array and the macro's are still necessary, since the raw data still needs to be interpreted to take into account differences in endianness or floating point types if GDB runs on a host with a different architecture than the target. Mark >From brg@sartre.dgate.ORG Sat Apr 01 00:00:00 2000 From: "Brian R. Gaeke" To: Stan Shebs Cc: gcc@gcc.gnu.org, gdb@sourceware.cygnus.com Subject: Re: Should GCC tell GDB about its optimizations? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000303173847.A1487@celes.dgate.ORG> References: <38C051C3.260D666B@apple.com> X-SW-Source: 2000-q1/msg00532.html Content-length: 1596 And then spake Stan Shebs, as follows: > Ideally of course, GCC would issue lots of amazingly detailed debug info, > and GDB would use it to reconstruct and report program state just as the > programmer expects to see it. But today, the result is just lame; hackers > trying to debug get lots of squirrelly behavior from GDB. The problem is > that they don't know whether the randomness is due to bugs in the program, > or to the effect of the optimizer. So the suggestion came up to have GCC > issue debug info stating what optimizations have been applied to a file, > and to have GDB report that information per-function, so that users could > lower their expectations appropriately. You may (or perhaps may not) find some of the material Caroline Tice has worked on here at UCB useful -- ISTR she was investigating debugging optimized code and did work on a compiler that outputted a lot of information on the transformations that were applied to the code (and debugging tools that used it.) Disclaimer: I don't have any direct knowledge of how her code did what it did, so I can't really be of much help -- but I just thought that her dissertation talk sounded a lot like what you are trying to do... http://sunsite.berkeley.edu/Dienst/UI/2.0/Describe/ncstrl.ucb/CSD-99-1077 http://www.cs.berkeley.edu/~cmtice/ -Brian -- Brian R. Gaeke, brg@sartre.dgate.ORG -- PGP/GPG gleefully accepted "the iguana / in the petshop window on St Catherine Street / crested, royal-eyed, ruling / its kingdom of water-dish and sawdust / dreams of sawdust" - Margaret Atwood, "Dreams of the Animals" >From Rene.Affourtit@pemstar.nl Sat Apr 01 00:00:00 2000 From: Rene.Affourtit@pemstar.nl To: ecos-discuss@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: cl7111 and gdb problem Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: X-SW-Source: 2000-q1/msg00756.html Content-length: 2154 hello, I have a question concerning the use of the arm-elf-gdb debugger and the CL7111-2 development board. When trying to talk to angel in the cl7111 board using the rdi protocol as described in the documentation gdb prints the following message: "RDI_open: undefined error message, should reset target" and does not respond anymore. I was wondering if anyone else has experienced this problem. There was a similar message in feb. 2000 (subject line : Problem using Insight on ARM7 PID for debugging a ecos application), but I could not find an answer in the mailing list archive. any help will be appreciated. Rene Affourtit BTW: Is anybody else using the cl7111 target? Teh target system uses Angel version 1.04. bash.exe-2.02$ arm-elf-gdb --version GNU gdb 4.17-ecosSWtools-arm-990321 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. This version of GDB is supported for customers of Cygnus Solutions. Type "show warranty" for details. This GDB was configured as "--host=i586-cygwin32 --target=arm-elf". bash.exe-2.02$ bash.exe-2.02$ arm-elf-gdb GNU gdb 4.17-ecosSWtools-arm-990321 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. This version of GDB is supported for customers of Cygnus Solutions. Type "show warranty" for details. This GDB was configured as "--host=i586-cygwin32 --target=arm-elf". (gdb) set remotebaud 115200 (gdb) target rdi com1 DEBUG: Buffer allocated in angel_RDI_open(type=10). negotiate_params sent negotiate packet RDI_open: undefined error message, should reset target DEBUG: Entered angel_RDI_info. DEBUG: RDIInfo_Target. wait_for_debug_message waiting for 80010001 (indented lines are debug information genrated by gdb (rebuilt gbb with debug info on in ardi.c)