Mirror of the gdb mailing list
 help / color / mirror / Atom feed
  • [parent not found: <200003021246.e22CkWL00549@delius.kettenis.local>]
    • * 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
    * 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
    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 --
     [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     ` Regressions problem (200 failures) Mark Mitchell
     [not found]   ` <200003021246.e22CkWL00549@delius.kettenis.local>
2000-04-01  0:00     ` Peter.Schauer
2000-04-01  0:00     ` Mark Mitchell
2000-04-01  0:00 Hans-Bernhard Broeker
  -- 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