* Re: Regressions problem (200 failures)
@ 2000-04-01 0:00 Hans-Bernhard Broeker
0 siblings, 0 replies; 7+ messages in thread
From: Hans-Bernhard Broeker @ 2000-04-01 0:00 UTC (permalink / raw)
To: gdb; +Cc: Eli Zaretskii
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <200003021010.LAA13693@reisser.regent.e-technik.tu-muenchen.de>]
* Regressions problem (200 failures)
@ 2000-03-01 9:49 Donn Terry
2000-04-01 0:00 ` Donn Terry
[not found] ` <20000301123337B.mitchell@codesourcery.com>
0 siblings, 2 replies; 7+ messages in thread
From: Donn Terry @ 2000-03-01 9:49 UTC (permalink / raw)
To: 'gdb@sourceware.cygnus.com'; +Cc: 'mark@codesourcery.com'
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 <mark@codesourcery.com>
>
> * 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 <Guenther.Grau@marconicomms.com>
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> <npem9ulja1.fsf@zwingli.cygnus.com>
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 <tromey@cygnus.com>
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> <npem9ulja1.fsf@zwingli.cygnus.com> <38BD61EF.81A4E3C6@marconicomms.com>
X-SW-Source: 2000-03/msg00012.html
Content-length: 548
>>>>> "Guenther" == Guenther Grau <Guenther.Grau@marconicomms.com> 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 <mark@codesourcery.com>
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: <BB61526CDE70D2119D0F00805FBECA2F12A39A08@RED-MSG-55>
X-SW-Source: 2000-03/msg00013.html
Content-length: 677
>>>>> "Donn" == Donn Terry <donnte@microsoft.com> 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 <kingdon@redhat.com>
To: "Sharath Kumar" <sharathibm@theglobe.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: about breakpoints
Date: Wed, 01 Mar 2000 13:48:00 -0000
Message-id: <bg0ua4b10.fsf@rtl.cygnus.com>
References: <NPPAALHJCJDFIAAA@theglobe.com>
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 <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
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 <kingdon@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Dependence on config.status
Date: Wed, 01 Mar 2000 14:30:00 -0000
Message-id: <bem9u49sh.fsf@rtl.cygnus.com>
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 <kettenis@wins.uva.nl>
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 <ac131313@cygnus.com>
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" <gzp@gzp.org.hu>
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 <ac131313@cygnus.com>
To: "Gabor Z. Papp" <gzp@gzp.org.hu>
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" <gzp@gzp.org.hu>
To: Andrew Cagney <ac131313@cygnus.com>
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 <kingdon@redhat.com>
To: Mark Mitchell <mark@codesourcery.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Regressions problem (200 failures)
Date: Wed, 01 Mar 2000 20:13:00 -0000
Message-id: <bd7pe3t7t.fsf@rtl.cygnus.com>
References: <BB61526CDE70D2119D0F00805FBECA2F12A39A08@RED-MSG-55> <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 <kingdon@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: [MAINT/RFC] Start devolving maintenance responsibility
Date: Wed, 01 Mar 2000 20:34:00 -0000
Message-id: <bbt4y3s8k.fsf@rtl.cygnus.com>
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 <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
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 <mark@codesourcery.com>
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: <BB61526CDE70D2119D0F00805FBECA2F12A39A08@RED-MSG-55> <20000301123337B.mitchell@codesourcery.com> <bd7pe3t7t.fsf@rtl.cygnus.com>
X-SW-Source: 2000-03/msg00024.html
Content-length: 718
>>>>> "Jim" == Jim Kingdon <kingdon@redhat.com> 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 <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
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> <bbt4y3s8k.fsf@rtl.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 <wait.h> -> "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 <eliz@delorie.com>
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> <bem9u49sh.fsf@rtl.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" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
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: <bd7pe3t7t.fsf@rtl.cygnus.com>
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 <mark@codesourcery.com>
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: <bd7pe3t7t.fsf@rtl.cygnus.com> <200003021010.LAA13693@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-03/msg00028.html
Content-length: 762
>>>>> "Peter" == Peter Schauer <Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE> 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" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
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 <muller@cerbere.u-strasbg.fr>
To: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
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 <muller@cerbere.u-strasbg.fr>
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 <kettenis@wins.uva.nl>
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: <bd7pe3t7t.fsf@rtl.cygnus.com> <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 <mark@codesourcery.com>
Date: Thu, 02 Mar 2000 02:34:20 -0800
>>>>> "Peter" == Peter Schauer <Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE> 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" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
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 <kettenis@wins.uva.nl>
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 <muller@cerbere.u-strasbg.fr>
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 <muller@cerbere.u-strasbg.fr>
To: Mark Kettenis <kettenis@wins.uva.nl>
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 <muller@cerbere.u-strasbg.fr>
>
> 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 <kettenis@wins.uva.nl>
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 <muller@cerbere.u-strasbg.fr>
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 <muller@cerbere.u-strasbg.fr>
>
> 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 <muller@cerbere.u-strasbg.fr>
To: Mark Kettenis <kettenis@wins.uva.nl>
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 <muller@cerbere.u-strasbg.fr>
> 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 <muller@cerbere.u-strasbg.fr>
> >
> > 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 <muller@cerbere.u-strasbg.fr>
To: Mark Kettenis <kettenis@wins.uva.nl>
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 <kingdon@redhat.com>
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> <bbt4y3s8k.fsf@rtl.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 <ac131313@cygnus.com>
To: Pierre Muller <muller@cerbere.u-strasbg.fr>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, 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 <eliz@delorie.com>
To: Pierre Muller <muller@cerbere.u-strasbg.fr>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, 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 <kettenis@wins.uva.nl>
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 <muller@cerbere.u-strasbg.fr>
>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 <kettenis@wins.uva.nl>
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 <muller@cerbere.u-strasbg.fr>
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 <muller@cerbere.u-strasbg.fr>
To: Mark Kettenis <kettenis@wins.uva.nl>
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 <muller@cerbere.u-strasbg.fr>
>
> >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 <broeker@physik.rwth-aachen.de>
To: gdb@sourceware.cygnus.com
Cc: Eli Zaretskii <eliz@is.elta.co.il>
Subject: Re: Regressions problem (200 failures)
Date: Thu, 02 Mar 2000 08:00:00 -0000
Message-id: <Pine.LNX.4.10.10003021658190.11752-100000@acp3bf>
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* Regressions problem (200 failures)
2000-03-01 9:49 Donn Terry
@ 2000-04-01 0:00 ` Donn Terry
[not found] ` <20000301123337B.mitchell@codesourcery.com>
1 sibling, 0 replies; 7+ messages in thread
From: Donn Terry @ 2000-04-01 0:00 UTC (permalink / raw)
To: 'gdb@sourceware.cygnus.com'; +Cc: 'mark@codesourcery.com'
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 <mark@codesourcery.com>
>
> * 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 <ezannoni@cygnus.com>
To: Eli Zaretskii <eliz@delorie.com>
Cc: Pierre Muller <muller@cerbere.u-strasbg.fr>, gdb@sourceware.cygnus.com, Elena Zannoni <ezannoni@cygnus.com>
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" <hjl@lucon.org>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, 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 <hjl@lucon.org> 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 <shebs@apple.com>
To: Jim Kingdon <kingdon@redhat.com>
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> <bitzw8fvy.fsf@rtl.cygnus.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 <shebs@apple.com>
To: Daniel Berlin <dan@cgsoftware.com>
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: <Pine.LNX.4.10.10002170818250.24672-100000@propylaea.anduin.com>
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 <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
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: <Pine.LNX.4.10.10003130853520.6968-100000@localhost.localdomain> <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 <ac131313@cygnus.com>
To: Jason Molenda <jsm@cygnus.com>
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" <hjl@lucon.org>
To: GDB <gdb@sourceware.cygnus.com>
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 <ac131313@cygnus.com>
To: Paul Breed <pbreed@yahoo.com>
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 <cagney@b1.cygnus.com>
* 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 <kettenis@wins.uva.nl>
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 <eliz@delorie.com>
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" <brg@sartre.dgate.ORG>
To: Stan Shebs <shebs@apple.com>
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: <OF616F8594.4CEC3BB0-ONC12568A9.004FE2E7@pemstar.nl>
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)
^ permalink raw reply [flat|nested] 7+ messages in thread[parent not found: <20000301123337B.mitchell@codesourcery.com>]
* Re: Regressions problem (200 failures)
[not found] ` <20000301123337B.mitchell@codesourcery.com>
@ 2000-04-01 0:00 ` Jim Kingdon
0 siblings, 0 replies; 7+ messages in thread
From: Jim Kingdon @ 2000-04-01 0:00 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gdb
> 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 aj@suse.de Sat Apr 01 00:00:00 2000
From: Andreas Jaeger <aj@suse.de>
To: shebs@shebs.cnchost.com
Cc: gdb@sourceware.cygnus.com, linux390@de.ibm.com
Subject: Re: GDB for S390
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <u8og9ussad.fsf@gromit.rhein-neckar.de>
References: <389CB0ED.755AD37C@shebs.cnchost.com>
X-SW-Source: 2000-q1/msg00114.html
Content-length: 769
>>>>> Stan Shebs writes:
> Noticed this while surfing in strange corners of the web:
> http://www.software.ibm.com/developerworks/opensource/linux390/download_src.html
> Not only is there a port of Linux to IBM's 390 mainframes,
> but the GCC and GDB patches are available! GDB patches
> are against 4.18 and at first glance seem reasonable; we
> should contact those guys and get them to donate...
There're also glibc and binutils patches ;-).
I hope that these will soon be integrated (so far the patches have only
be added to the Linux 2.2 kernel) I'm CC'ing the linux390
developers - perhaps one of them can clarify the situation? Or just donate
the port;-).
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.rhein-neckar.de
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb@sourceware.cygnus.com
Cc: Eric Bachalo <ebachalo@cygnus.com>, Franz Sirl <Franz.Sirl-kernel@lauterbach.com>, khendricks@admin.ivey.uwo.ca
Subject: Linux/PPC support (was Re: Preparing for the GDB 5.0 ... release)
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000209051829.ZM2093@ocotillo.lan>
References: <00020900262503.05214@enzo.bigblue.local> <Franz.Sirl-kernel@lauterbach.com>
X-SW-Source: 2000-q1/msg00185.html
Content-length: 1659
I am at least partially to blame for nothing happening with regard to
getting the linux/ppc patches merged and committed to cvs. My excuse
is that I've been assigned some challenging work that has sucked up
all of my work time as well as much of my personal time.
Earlier today, I spoke to my manager about this situation and I've
gotten his agreement (I think) to spend a week getting linux/ppc
support merged and committed. :-) Better still, the week in question
is next week (2/14 thru 2/18, plus whatever I put in on the weekends).
The reason for doing it next week as opposed to some other random week
is that I'm in the midst of a two week stint of AIX work and it's
better for me to do it now when I'm focused on the PPC and related
architectures and have current (working) build trees for AIX. Plus,
once committed, it'll give those of you who use linux/ppc on a daily
basis a chance to put it through its paces before the next gdb
release.
When I did the gdb port for linux/ppc, I made a copy of rs6000-tdep.c
and converted it to use the SysV ABI (along with some other linux
specific details). At the time, this was the right decision since I
didn't have access to an AIX machine to build and test on. Had I
attempted to work directly in rs6000-tdep.c, I would almost certainly
have broken the AIX port. But now the situation is a bit different
and I think the right thing to do (maintenance-wise) is to merge
linux/ppc support into rs6000-tdep.c and (partially/minimally)
multi-arch the thing in the process. There will still be a separate
ppclinux-nat.c file though.
Okay?
Kevin
--
Kevin Buettner
kev@primenet.com, kevinb@redhat.com
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: ac131313@cygnus.com
Cc: aj@suse.de, gdb@sourceware.cygnus.com
Subject: Re: core dump from GNU/Linux <sys/procfs.h>; Was: Build failure on Linux/i686
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002110736.e1B7afa00398@delius.kettenis.local>
References: <u8d7q4j4df.fsf@gromit.rhein-neckar.de> <200002101919.UAA23595@landau.wins.uva.nl> <38A353C3.DDD9A240@cygnus.com>
X-SW-Source: 2000-q1/msg00219.html
Content-length: 1144
Date: Fri, 11 Feb 2000 11:11:47 +1100
From: Andrew Cagney <ac131313@cygnus.com>
Mark Kettenis wrote:
> This is the solution I proposed:
>
> http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00103.html
>
> Note that you'll need to patch <sys/procfs.h> too, otherwise GDB will
> segfault when you try to debug a multithreaded app!
Um, can you expand on this a little? (You may have already).
The first version of glibc that includes the threads debugging library
(libthread.so) will be 2.1.3, which has not been officially released
yet. Since both Andreas and I are glibc developers we were among the
first to test a GDB that makes use of that functionality apart from
the people who actually implemented it. It looks as if Ulrich Drepper
(the glibc maintainer) and Michael have let things go slighty out of
sync. So without patches to both GDB and the glibc prereleases it
won't work.
If there is a header file found in a standard GNU/Linux distribution
that can cause GDB to dump core we're going to need some sort of evasive
action. Sigh.
That's what I'm trying to prevent :-)
Mark
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: New file gdb/CONTRIBUTE guidelins for the contributor
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A3780F.2FE7A510@cygnus.com>
X-SW-Source: 2000-q1/msg00209.html
Content-length: 4972
Hello,
I'd like to put the attatched file forward as an addition to the other
readme files in the GDB directory.
Originally I was going to include this in the MAINTAINERS file but
decided that a separate file was probably of more benefit and more
likely to be noticed.
In terms of content, this really is a direct lift of GCC's
how-to-contribute page.
The one problem I can see at present is that the notes don't clearly
differentiate between GDB (src/gdb) and BINUTILS (src/bfd, src/include).
Andrew
Contributing to GDB
[much of this is lifted from the GCC page]
We strongly encourage contributions of code, bugfixes, new
optimizations, new features, documentation updates, tests, web page
improvements, etc. for GDB.
There are certain legal requirements and style issues which all
contributions must meet.
o Coding Standards
All contributions must conform to the GNU Coding Standard.
http://www.gnu.ai.mit.edu/prep/standards_toc.html
Submissions which do not conform to the standards will be
returned with a request to reformat the changes.
For GDB, that standard is more tightly defined. GDB's
coding standard is determined by the output of
gnu-indent.
This situation came about because, by the start of '99,
GDB's coding style was so bad an inconsistent that it was
decided to restart things from scratch.
o Copyright Assignment
There are certain legal requirements
Before we can accept code contributions from you, we need a
copyright assignment form filled out.
If you've developed some addition or patch to GDB that you
would like to contribute, you should fill out a copyright
assignment form and send it in to the FSF. We are unable to
use code from you until this is on-file at the FSF, so get
that paperwork in! This form covers one batch of changes.
Ref: http://gcc.gnu.org/fsf-forms/assignment-instructions.html
If you think you're going to be doing continuing work on GDB, it
would be easier to use a different form, which arranges to
assign the copyright for all your future changes to GDB. It is
called assign.future. Please note that if you switch
employers, the new employer will need to fill out the
disclaim.future form; there is no need to fill out the
assign.future form again.
Ref: http://gcc.gnu.org/fsf-forms/assign.future
Ref: http://gcc.gnu.org/fsf-forms/disclaim.future
There are several other forms you can fill out for different
circumstances (e.g. to contribute an entirely new program, to
contribute significant changes to a manual, etc.)
Ref: http://gcc.gnu.org/fsf-forms/copyrights.html
Small changes can be accepted without a copyright assignment
form on file.
This is pretty confusing! If you are unsure of what is
necessary, just ask the GCC mailing list and we'll figure out
what is best for you.
Note: Many of these forms have a place for "name of
program". Insert the name of one program in that place -- in
this case, "GDB".
o Submitting Patches
Every patch must have several pieces of information before we
can properly evaluate it.
A description of the bug and how your patch fixes this
bug. A reference to a testsuite failure is very helpful. For
new features a description of the feature and your
implementation.
A ChangeLog entry as plaintext (separate from the patch); see
the various ChangeLog files for format and content. Note that,
unlike some other projects, we do require ChangeLogs also for
documentation (i.e., .texi files).
The patch itself. If you are accessing the CVS repository at:
Cygnus, use "cvs update; cvs diff -c3p"; else, use "diff -c3p
OLD NEW" or "diff -up OLD NEW". If your version of diff does
not support these options, then get the latest version of GNU
diff.
We accept patches as plain text (preferred for the compilers
themselves), MIME attachments (preferred for the web pages),
or as uuencoded gzipped text.
When you have all these pieces, bundle them up in a mail
message and send it to gdb-patches@sourceware.cygnus.com. All
patches and related discussion should be sent to the
gcc-patches mailinglist. For further information on the GDB
CVS repository, see the Anonymous read-only CVS access and
Read-write CVS access page.
--
Supplemental information for GDB:
o Please try to run the relevant testsuite before and after
committing a patch
If the contributor doesn't do it then the maintainer will. A
contributor might include before/after test results in their
contribution.
o For bug fixes, please try to include a way of
demonstrating that the patch actually fixes something.
The best way of doing this is to ensure that the
testsuite contains one or more test cases that
fail without the fix but pass with the fix.
People are encouraged to submit patches that extend
the testsuite.
o Please read your patch before submitting it.
A patch containing several unrelated changes or
arbitrary reformats will be returned with a request
to re-formatting / split it.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2000-04-01 0:00 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-01 0:00 Regressions problem (200 failures) Hans-Bernhard Broeker
[not found] <200003021010.LAA13693@reisser.regent.e-technik.tu-muenchen.de>
[not found] ` <20000302023420H.mitchell@codesourcery.com>
[not found] ` <200003021143.MAA14294@reisser.regent.e-technik.tu-muenchen.de>
2000-03-02 8:56 ` Mark Mitchell
[not found] ` <200003021246.e22CkWL00549@delius.kettenis.local>
2000-04-01 0:00 ` Mark Mitchell
2000-04-01 0:00 ` Peter.Schauer
-- strict thread matches above, loose matches on Subject: below --
2000-03-01 9:49 Donn Terry
2000-04-01 0:00 ` Donn Terry
[not found] ` <20000301123337B.mitchell@codesourcery.com>
2000-04-01 0:00 ` Jim Kingdon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox