* 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 Regressions problem (200 failures) 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
* 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
* Re: Regressions problem (200 failures)
[not found] ` <200003021246.e22CkWL00549@delius.kettenis.local>
2000-04-01 0:00 ` Mark Mitchell
@ 2000-04-01 0:00 ` Peter.Schauer
1 sibling, 0 replies; 7+ messages in thread
From: Peter.Schauer @ 2000-04-01 0:00 UTC (permalink / raw)
To: Mark Kettenis; +Cc: gdb
> 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 ezannoni@cygnus.com Sat Apr 01 00:00:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Michael Meissner <meissner@cygnus.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: mdebug?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <14563.55263.898978.669684@kwikemart.cygnus.com>
References: <14563.50531.341290.804769@kwikemart.cygnus.com> <20000330165810.27223@cse.cygnus.com>
X-SW-Source: 2000-q1/msg00844.html
Content-length: 1301
Michael Meissner writes:
> On Thu, Mar 30, 2000 at 04:21:39PM -0500, Elena Zannoni wrote:
> >
> > Does anybody know something about mdebug?
>
> In the past, I knew something of the format. Unfortunately, the only document
> I ever saw on it (other than the DEC include files) is a hard copy of the DEC
> Pmax assembler guide, that I may have somewhere.
>
> > I am trying to figure out a problem in gdb which untilmately is due
> > to some limitation of mdebug.
> > Is there any documentation at all about how the debug symbols are built?
>
> The program mips-tdump.c in the gcc release, in the distant past dumped the
> debug tables for MIPS and later Alpha ecoff systems. Whether it has suffered
> bit rot in the 9+ years since I wrote it, I don't know.
>
> --
> Michael Meissner, Cygnus Solutions, a Red Hat company.
> PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
> Work: meissner@redhat.com phone: +1 978-486-9304
> Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482
Thanks Mike.
I also found that this document at:
http://reality.sgi.com/davea/objectinfo.html
has a pointer to a mdebug.ps file containing some description of the mdebug
format. In this, there is mention of an SGI utility available on IRIX
called stdump.
Elena
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: kevinb@cygnus.com
Cc: ac131313@cygnus.com, scottb@netwinder.org, gdb@sourceware.cygnus.com
Subject: Re: store_floating() rewrite (was Re: bug in arm_push_arguments())
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002281929.UAA03907@landau.wins.uva.nl>
References: <38B6C4A1.7A1461C4@netwinder.org> <38BA642A.6F358273@cygnus.com> <1000228181141.ZM26089@ocotillo.lan>
X-SW-Source: 2000-q1/msg00442.html
Content-length: 1583
Date: Mon, 28 Feb 2000 11:11:42 -0700
From: Kevin Buettner <kevinb@cygnus.com>
On Feb 28, 11:03pm, Andrew Cagney wrote:
> Kevin Buttner wrote:
> > It seems to me that you should be able to use store_floating() to do
> > what you want. It'll handle both the conversion and the byte swapping.
>
> Yes, that looks correct. I'm just not 100% sure on it working - would
> one of those if()'s before the TARGET_EXTRACT_FLOATING() get in the way?
^^^^^^^^^^^^^^^^^^^^^^^
Did you mean TARGET_STORE_FLOATING?
Andrew was probably looking at extract_floating() which suffers from
the same braindamage as you describe. This needs to be fixed,
and I think your patch is basically right. Apart from store_floating
and extract_floating, there are probably some other functions where
the same assumptions are made.
However, keep in mind that we must guard for loss of precision. What
should store_floating do if DOUBLEST (which "lives" on the host) has
less precision than the target type in which it is being stored? This
is also a problem with a somewhat wider scope. There is no explicit
policy in GDB on which operations are allowed to lose precision, and
which operations are not supposed to lose precision. I think that if
we're going to address the issues raised here, we must determine such
a policy, and document it.
Please also keep in mind that TARGET_STORE_FLOATING and
TARGET_EXTRACT_FLOATING really should be eliminated. They are part of
a workaround for the problem that's being adressed now and are only
used on Linux/i386.
Mark
From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: davea@dsl-quasar.corp.sgi.com (David B. Anderson)
Cc: gdb@sourceware.cygnus.com
Subject: Re: mdebug
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <14565.12523.449478.621361@kwikemart.cygnus.com>
References: <200003312258.OAA25181@dsl-quasar.corp.sgi.com>
X-SW-Source: 2000-q1/msg00848.html
Content-length: 1410
Thanks David, I did find your paper.
And yes, I have a specific question. Does mdebug let the user specify
a procedure like 'main()' in a section other than .text?
Thanks
Elena
David B. Anderson writes:
>
>
>
> Elena Zannoni <ezannoni@cygnus.com> writes:
> >Does anybody know something about mdebug?
>
> Yes.
>
> >I am trying to figure out a problem in gdb which untilmately is due
> >to some limitation of mdebug.
> >Is there any documentation at all about how the debug symbols are built?
>
> http://reality.sgi.com/davea/objectinfo.html
> Look early in the page for:
>
> one part of the old 32bit ABI for MIPS
> is the mdebug debugging information.
> A postscript file with the only currently
> available description of this data is here (119Kbytes)
>
> It is is an old paper I wrote on mdebug.
> Not too well written, but... what else is there?
> Perhaps it will help. Does not mention limits, though.
> The limits are implicit in various structs. Perhaps
> 'explicit' is a better word :-)
>
> If you have any questions let me know.
> (whether I'll know the answer is something else...)
>
> I don't know too much about DEC or other *extensions*
> to mdebug. Just sgi's. But there are certainly some
> important limitations in mdebug. Like 64K procedures (at most).
> SGI did some hack extensions, but ... never mind.
>
> davea@sgi.com
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: dan@cgsoftware.com
Cc: gdb@sourceware.cygnus.com, dj@delorie.com, ac131313@cygnus.com
Subject: Re: 000217: status of DJGPP support
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002202209.RAA13439@indy.delorie.com>
References: <Pine.LNX.4.10.10002201158010.1564-100000@propylaea.anduin.com>
X-SW-Source: 2000-q1/msg00356.html
Content-length: 541
> I have this problem on BeOS.
> I can give you an fd_mask that will work.
Thanks, but it won't be necessary: I already crafted a definition that
works with DJGPP.
I'm not sure where's the appropriate place to put the typedef for
fd_mask. Can you tell me where did you put yours?
> Unfortunately, i had to disable the event loop based interface because
> our select isn't good enough yet.
Out of curiosity: can you tell what functionality is missing from your
select? I'd like to double-check that the DJGPP version will work.
Thanks.
From law@cygnus.com Sat Apr 01 00:00:00 2000
From: Jeffrey A Law <law@cygnus.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Daniel Berlin <dan@cgsoftware.com>, 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: <4046.949979695@upchuck>
References: <27617.949979286@sss.pgh.pa.us>
X-SW-Source: 2000-q1/msg00153.html
Content-length: 770
In message < 27617.949979286@sss.pgh.pa.us >you write:
> Daniel Berlin <dan@cgsoftware.com> writes:
> >> Debugging shared libraries works most of time with gdb 4.17.0.14.
> >> If it doesn't work with 5.0, does that count for serious losses of
> >> functionality?
>
> > You mean for your particular architecture.
>
> I don't know what architecture H.J. is using, but I can tell you that
> shared lib debugging is completely nonfunctional on HPPA (HPUX 10.20).
> Can't even get a backtrace when execution is stopped in a shlib...
> kind of puts a crimp in the usefulness of gdb, at least for me.
Testcases please? If it's busted, it's news to me. This stuff was rock
solid when I stopped working on the PA port regularly a few years ago.
jeff
^ permalink raw reply [flat|nested] 7+ messages in thread
* 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
* Re: Regressions problem (200 failures)
[not found] ` <200003021246.e22CkWL00549@delius.kettenis.local>
@ 2000-04-01 0:00 ` Mark Mitchell
2000-04-01 0:00 ` Peter.Schauer
1 sibling, 0 replies; 7+ messages in thread
From: Mark Mitchell @ 2000-04-01 0:00 UTC (permalink / raw)
To: kettenis; +Cc: Peter.Schauer, kingdon, donnte, gdb
>>>>> "Mark" == Mark Kettenis <kettenis@wins.uva.nl> writes:
Mark> some bit rot since then. Are the prologue's generated by
Mark> GCC any different from those generated back in 1994?
I dunno, but my guess is that's not the bug.
Right now, the problem is:
o We put line notes in the prologue
o We weren't putting line notes before the first real code, so
GCC was skipping over that too.
o I promoted the last line note in the prologue to appear before
the first real code, bringing GCC back to seme-sensible behavior.
We could try to:
o Not emit line notes in the prologue that correspond to the '{'
line.
o Try to find the first line note in the real code, instead of
the last line note in the prologue.
The latter is probably easiest, but is still harder that what I did.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ezannoni@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Buffering problems with "gdb < foo"
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003070817.DAA14441@indy.delorie.com>
References: <200003050850.DAA10185@indy.delorie.com> <14531.61750.823726.628635@kwikemart.cygnus.com>
X-SW-Source: 2000-q1/msg00555.html
Content-length: 676
> > Does this work on Unix? If so, it would make this a DJGPP-specific
> > problem.
>
> I haven't tried, but probably it won't. Can you send me your command file?
It is simply "gdb < foo > bar". The input file `foo' looks like this:
shell gcc -g -o t.exe t.c
file t.exe
dir
y
dir .
break main
run
q
y
(If needed, I can send the exact file used for the input.) Try this,
and you will see that GDB exits immediately after it processes the
first "dir" command.
> > If this is not DJGPP-specific, then I think _initialize_event_loop
> > should turn editing off if input_fd is not a tty.
>
> I think so, can you submit a patch to do this?
Will do.
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: cgf@cygnus.com
Cc: toddpw@windriver.com, gdb@sourceware.cygnus.com
Subject: Re: Readline and -DMINIMAL
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003312329.SAA07193@indy.delorie.com>
References: <200003281230.EAA15638@alabama.wrs.com> <20000328105123.G27306@cygnus.com>
X-SW-Source: 2000-q1/msg00851.html
Content-length: 397
> The readline directory in CVS is version
> 4.0 with changes from Eli Zaretskii (I hope he also notified the readline
> maintainer about these) to get things working on DJGPP.
I checked my patches against the recent beta version of Readline, and
all the changes are already taken care of there (the person who ported
Bash to DJGPP submitted almost identical patches to the Readline
maintainer).
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: akale@veritas.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Regression caused by elfread.c patch
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002150453.XAA11268@devserv.devel.redhat.com>
References: <200002142206.e1EM6a310093@delius.kettenis.local> <00021509472500.20543@fermat.vxindia.veritas.com>
X-SW-Source: 2000-q1/msg00286.html
Content-length: 405
> That was because Jim didn't checkin my patch correctly.
> He has fixed it now.
No, this is a different problem.
I don't see how your patch could work at all - sym->section->index is
a very different number than a SECT_OFF_* code. The SECT_OFF_* code
(which gets fed to ANOFFSET) isn't computed until later in the
function (via the call to record_minimal_symbol_and_info).
I have reverted the patch.
From fnasser@cygnus.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Variable objects code now available in gdb
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A30E4E.B757E57E@cygnus.com>
X-SW-Source: 2000-q1/msg00203.html
Content-length: 830
The Insight GUI had a neat code, written by Keith Seitz, which allows
for the tracking of variables and expressions. This is used by Insight
to implement its Local Variables and Watch Expression windows.
As this is can be really useful to script languages and most of the code
was written in C, we decided to extract it and make it available on the
gdb library.
I have created a C API, fixed a few things and added the files varobj.c
and varobj.h to gdb. There is also a wrapper.c file which provides
longjump free calls to some gdb utility routines.
P.S.: Insight was modified to use this new code as well.
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From echristo@cygnus.com Sat Apr 01 00:00:00 2000
From: Eric Christopher <echristo@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: Has anyone compiled gdb from CVS on Linux?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A20644.99DEB7A6@cygnus.com>
References: <20000208190825.A17306@lucon.org> <bn1pbnf4d.fsf@rtl.cygnus.com>
X-SW-Source: 2000-q1/msg00195.html
Content-length: 1366
The define is in the config.h file that gdb_wait.h needs to include
<sys/wait.h>. It doesn't seem to be included either in linux-thread.c
or gdb_wait.h. I'm guessing it should
be?
from gdb/config.h:
/* Define if you have the <sys/wait.h> header file. */
#define HAVE_SYS_WAIT_H 1
and gdb/gdb_wait.h
/#ifdef HAVE_SYS_WAIT_H
#include <sys/wait.h> /* POSIX */
#else
#ifdef HAVE_WAIT_H
#include <wait.h> /* legacy */
#endif
#endif
-eric
>
> > I cannot compile gdb from CVS on Linux since the merge. For one thing,
> > include/wait.h doesn't have
>
> I got around this by the enclosed patch (all that HAVE_WAIT_H looks
> like pre-POSIX cruft to me). I haven't tried to turn this into an
> official submission (yet, at least).
>
> With this patch, it compiles and runs for me.
>
> Index: lin-thread.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/lin-thread.c,v
> retrieving revision 1.1.1.1
> diff -u -r1.1.1.1 lin-thread.c
> --- lin-thread.c 1999/12/22 21:45:07 1.1.1.1
> +++ lin-thread.c 2000/02/09 04:45:14
> @@ -102,13 +102,7 @@
> #include "inferior.h"
> #include "gdbcmd.h"
>
> -#ifdef HAVE_WAIT_H
> -#include <wait.h>
> -#else
> -#ifdef HAVE_SYS_WAIT_H
> #include <sys/wait.h>
> -#endif
> -#endif
>
> /* "wait.h" fills in the gaps left by <wait.h> */
> #include "wait.h"
From jimb@zwingli.cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: unloading shared objects
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003102115.QAA15516@zwingli.cygnus.com>
X-SW-Source: 2000-q1/msg00672.html
Content-length: 28044
I think I've got some code mostly working for this, but free_objfile
is tangled up with CLEAR_SOLIB in a way that is causing problems.
It'll take a little more work, but I think I'll have something ready
soon.
Unfortunately, it's not done right now, and I'll be gone for the
entire weekend, so the earliest I could possibly have anything working
would be Monday. I don't know how that interacts with our hopes for
GDB 5.0.
In case some enterprising soul wants to take it the rest of the way
while I'm gone, I've enclosed my patches below. I think the basic
logic is okay; known issues are:
- free_objfile calls CLEAR_SOLIB, which isn't what we want, I think.
- Selecting a core file and attaching to a process both add the shared
libraries' sections to the target_ops structure. When we unload a
shared library, we close the BFD those sections refer to. We
need to remove those sections from the target_ops structure.
And finally:
- Should solib.c be maintaining its own list of shared objects at all,
or should it always retrieve the full link map from the inferior,
and use the objfile list itself as our record of what we know about?
In other words, what does so_list_head offer that object_files doesn't
do better?
Anyway, I'll finish these when I get back, if nobody else does. I'd
love comments on the changes.
Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.2
diff -c -r1.2 solib.c
*** solib.c 2000/03/06 18:04:56 1.2
--- solib.c 2000/03/10 21:09:51
***************
*** 136,153 ****
struct so_list
{
struct so_list *next; /* next structure in linked list */
struct link_map lm; /* copy of link map from inferior */
struct link_map *lmaddr; /* addr in inferior lm was read from */
CORE_ADDR lmend; /* upper addr bound of mapped object */
- char so_name[MAX_PATH_SIZE]; /* shared object lib name (FIXME) */
char symbols_loaded; /* flag: symbols read in yet? */
char from_tty; /* flag: print msgs? */
struct objfile *objfile; /* objfile for loaded lib */
struct section_table *sections;
struct section_table *sections_end;
struct section_table *textsection;
- bfd *abfd;
};
static struct so_list *so_list_head; /* List of known shared objects */
--- 136,171 ----
struct so_list
{
+ /* The following fields of the structure come directly from the
+ dynamic linker's tables in the inferior, and are initialized by
+ current_sos. */
+
struct so_list *next; /* next structure in linked list */
struct link_map lm; /* copy of link map from inferior */
struct link_map *lmaddr; /* addr in inferior lm was read from */
+
+ /* Shared object file name, exactly as it appears in the
+ inferior's link map. This may be a relative path, or something
+ which needs to be looked up in LD_LIBRARY_PATH, etc. We use it
+ to tell which entries in the inferior's dynamic linker's link
+ map we've already loaded. */
+ char so_original_name[MAX_PATH_SIZE];
+
+ /* shared object file name, expanded to something GDB can open */
+ char so_name[MAX_PATH_SIZE];
+
+ /* The following fields of the structure are built from
+ information gathered from the shared object file itself, and
+ are initialized when we actually add it to our symbol tables. */
+
+ bfd *abfd;
CORE_ADDR lmend; /* upper addr bound of mapped object */
char symbols_loaded; /* flag: symbols read in yet? */
char from_tty; /* flag: print msgs? */
struct objfile *objfile; /* objfile for loaded lib */
struct section_table *sections;
struct section_table *sections_end;
struct section_table *textsection;
};
static struct so_list *so_list_head; /* List of known shared objects */
***************
*** 168,174 ****
match_main PARAMS ((char *));
static void
! special_symbol_handling PARAMS ((struct so_list *));
static void
sharedlibrary_command PARAMS ((char *, int));
--- 186,192 ----
match_main PARAMS ((char *));
static void
! special_symbol_handling PARAMS ((void));
static void
sharedlibrary_command PARAMS ((char *, int));
***************
*** 181,189 ****
static int symbol_add_stub PARAMS ((PTR));
- static struct so_list *
- find_solib PARAMS ((struct so_list *));
-
static struct link_map *
first_link_map_member PARAMS ((void));
--- 199,204 ----
***************
*** 199,204 ****
--- 214,223 ----
#else
+ static struct so_list *current_sos (void);
+ static void free_so (struct so_list *node);
+ static void sync_solibs (struct target_ops *target);
+
static int
disable_break PARAMS ((void));
***************
*** 854,860 ****
Find the first element in the inferior's dynamic link map, and
return its address in the inferior. This function doesn't copy the
! link map entry itself into our address space; find_solib actually
does the reading. */
static struct link_map *
--- 873,879 ----
Find the first element in the inferior's dynamic link map, and
return its address in the inferior. This function doesn't copy the
! link map entry itself into our address space; current_sos actually
does the reading. */
static struct link_map *
***************
*** 951,1091 ****
}
#endif /* SVR4_SHARED_LIBS */
- /*
! LOCAL FUNCTION
! find_solib -- step through list of shared objects
SYNOPSIS
! struct so_list *find_solib (struct so_list *so_list_ptr)
DESCRIPTION
! This module contains the routine which finds the names of any
! loaded "images" in the current process. The argument in must be
! NULL on the first call, and then the returned value must be passed
! in on subsequent calls. This provides the capability to "step" down
! the list of loaded objects. On the last object, a NULL value is
! returned.
! The arg and return value are "struct link_map" pointers, as defined
! in <link.h>.
! */
!
! static struct so_list *
! find_solib (so_list_ptr)
! struct so_list *so_list_ptr; /* Last lm or NULL for first one */
{
! struct so_list *so_list_next = NULL;
! struct link_map *lm = NULL;
! struct so_list *new;
! if (so_list_ptr == NULL)
{
! /* We are setting up for a new scan through the loaded images. */
! if ((so_list_next = so_list_head) == NULL)
! {
! /* We have not already read in the dynamic linking structures
! from the inferior, lookup the address of the base structure. */
! debug_base = locate_base ();
! if (debug_base != 0)
! {
! /* Read the base structure in and find the address of the first
! link map list member. */
! lm = first_link_map_member ();
! }
! }
}
! else
{
! /* We have been called before, and are in the process of walking
! the shared library list. Advance to the next shared object. */
! if ((lm = LM_NEXT (so_list_ptr)) == NULL)
! {
! /* We have hit the end of the list, so check to see if any were
! added, but be quiet if we can't read from the target any more. */
! int status = target_read_memory ((CORE_ADDR) so_list_ptr->lmaddr,
! (char *) &(so_list_ptr->lm),
! sizeof (struct link_map));
! if (status == 0)
! {
! lm = LM_NEXT (so_list_ptr);
! }
! else
! {
! lm = NULL;
! }
! }
! so_list_next = so_list_ptr->next;
}
! if ((so_list_next == NULL) && (lm != NULL))
{
! /* Get next link map structure from inferior image and build a local
! abbreviated load_map structure */
! new = (struct so_list *) xmalloc (sizeof (struct so_list));
! memset ((char *) new, 0, sizeof (struct so_list));
! new->lmaddr = lm;
! /* Add the new node as the next node in the list, or as the root
! node if this is the first one. */
! if (so_list_ptr != NULL)
! {
! so_list_ptr->next = new;
! }
! else
! {
! so_list_head = new;
! if (!solib_cleanup_queued)
! {
! make_run_cleanup (do_clear_solib, NULL);
! solib_cleanup_queued = 1;
! }
! }
! so_list_next = new;
read_memory ((CORE_ADDR) lm, (char *) &(new->lm),
sizeof (struct link_map));
/* For SVR4 versions, the first entry in the link map is for the
inferior executable, so we must ignore it. For some versions of
SVR4, it has no name. For others (Solaris 2.3 for example), it
does have a name, so we can no longer use a missing name to
decide when to ignore it. */
! if (!IGNORE_FIRST_LINK_MAP_ENTRY (new->lm))
{
int errcode;
char *buffer;
target_read_string ((CORE_ADDR) LM_NAME (new), &buffer,
MAX_PATH_SIZE - 1, &errcode);
if (errcode != 0)
{
! warning ("find_solib: Can't read pathname for load map: %s\n",
safe_strerror (errcode));
- return (so_list_next);
}
! strncpy (new->so_name, buffer, MAX_PATH_SIZE - 1);
! new->so_name[MAX_PATH_SIZE - 1] = '\0';
! free (buffer);
! catch_errors (solib_map_sections, new,
! "Error while mapping shared library sections:\n",
! RETURN_MASK_ALL);
}
}
! return (so_list_next);
}
/* A small stub to get us past the arg-passing pinhole of catch_errors. */
static int
symbol_add_stub (arg)
PTR arg;
{
! register struct so_list *so = (struct so_list *) arg; /* catch_errs bogon */
CORE_ADDR text_addr = 0;
- struct section_addr_info section_addrs;
! memset (§ion_addrs, 0, sizeof (section_addrs));
if (so->textsection)
text_addr = so->textsection->addr;
else if (so->abfd != NULL)
--- 970,1160 ----
}
#endif /* SVR4_SHARED_LIBS */
! /* LOCAL FUNCTION
! free_so --- free a `struct so_list' object
SYNOPSIS
! void free_so (struct so_list *so)
DESCRIPTION
! Free the storage associated with the `struct so_list' object *SO,
! and remove it from GDB's symbol tables, if it was there. Don't
! worry about unlinking it from the shared object list; the caller
! must handle that.
!
! This can be applied to both shared objects in GDB's list, or
! objects just obtained from current_sos, which don't have BFD's or
! objfiles created for them. */
! static void
! free_so (struct so_list *so)
{
! char *bfd_filename = 0;
!
! if (so->objfile)
! free_objfile (so->objfile);
! if (so->sections)
! free (so->sections);
!
! if (so->abfd)
{
! bfd_filename = bfd_get_filename (so->abfd);
! if (! bfd_close (so->abfd))
! warning ("cannot close \"%s\": %s",
! bfd_filename, bfd_errmsg (bfd_get_error ()));
}
!
! if (bfd_filename)
! free (bfd_filename);
!
! free (so);
! }
!
!
! /* On some systems, the only way to recognize the link map entry for
! the main executable file is by looking at its name. Return
! non-zero iff SONAME matches one of the known main executable names. */
!
! static int
! match_main (soname)
! char *soname;
! {
! char **mainp;
!
! for (mainp = main_name_list; *mainp != NULL; mainp++)
{
! if (strcmp (soname, *mainp) == 0)
! return (1);
}
!
! return (0);
! }
!
!
! /* LOCAL FUNCTION
!
! current_sos -- build a list of currently loaded shared objects
!
! SYNOPSIS
!
! struct so_list *current_sos ()
!
! DESCRIPTION
!
! Build a list of `struct so_list' objects describing the shared
! objects currently loaded in the inferior. This list does not
! include an entry for the main executable file.
!
! Note that we only gather information directly available from the
! inferior --- we don't examine any of the shared library files
! themselves. The declaration of `struct so_list' says which fields
! we provide values for. */
!
! static struct so_list *
! current_sos ()
! {
! struct link_map *lm;
! struct so_list *head = 0;
! struct so_list **link_ptr = &head;
!
! /* Make sure we've looked up the inferior's dynamic linker's base
! structure. */
! if (! debug_base)
{
! debug_base = locate_base ();
! /* If we can't find the dynamic linker's base structure, this
! must not be a dynamically linked executable. Hmm. */
! if (! debug_base)
! return 0;
! }
! /* Walk the inferior's link map list, and build our list of
! `struct so_list' nodes. */
! lm = first_link_map_member ();
! while (lm)
! {
! struct so_list *new
! = (struct so_list *) xmalloc (sizeof (struct so_list));
! memset (new, 0, sizeof (*new));
!
! new->lmaddr = lm;
read_memory ((CORE_ADDR) lm, (char *) &(new->lm),
sizeof (struct link_map));
+
+ lm = LM_NEXT (new);
+
/* For SVR4 versions, the first entry in the link map is for the
inferior executable, so we must ignore it. For some versions of
SVR4, it has no name. For others (Solaris 2.3 for example), it
does have a name, so we can no longer use a missing name to
decide when to ignore it. */
! if (IGNORE_FIRST_LINK_MAP_ENTRY (new->lm))
{
+ free_so (new);
+ }
+ else
+ {
int errcode;
char *buffer;
+
+ /* Extract this shared object's name. */
target_read_string ((CORE_ADDR) LM_NAME (new), &buffer,
MAX_PATH_SIZE - 1, &errcode);
if (errcode != 0)
{
! warning ("current_sos: Can't read pathname for load map: %s\n",
safe_strerror (errcode));
}
! else
! {
! strncpy (new->so_name, buffer, MAX_PATH_SIZE - 1);
! new->so_name[MAX_PATH_SIZE - 1] = '\0';
! free (buffer);
! strcpy (new->so_original_name, new->so_name);
! }
!
! /* If this entry has no name, or its name matches the name
! for the main executable, don't include it in the list. */
! if (! new->so_name[0]
! || match_main (new->so_name))
! free_so (new);
! else
! {
! new->next = 0;
! *link_ptr = new;
! link_ptr = &new->next;
! }
}
}
!
! return head;
}
+
/* A small stub to get us past the arg-passing pinhole of catch_errors. */
static int
symbol_add_stub (arg)
PTR arg;
{
! /* catch_errs bogon */
! register struct so_list *so = (struct so_list *) arg;
CORE_ADDR text_addr = 0;
! /* Have we already loaded this shared object? */
! ALL_OBJFILES (so->objfile)
! {
! if (strcmp (so->objfile->name, so->so_name) == 0)
! return 1;
! }
!
! /* Find the shared object's text segment. */
if (so->textsection)
text_addr = so->textsection->addr;
else if (so->abfd != NULL)
***************
*** 1094,1100 ****
/* If we didn't find a mapped non zero sized .text section, set up
text_addr so that the relocation in symbol_file_add does no harm. */
-
lowest_sect = bfd_get_section_by_name (so->abfd, ".text");
if (lowest_sect == NULL)
bfd_map_over_sections (so->abfd, find_lowest_section,
--- 1163,1168 ----
***************
*** 1104,1168 ****
+ (CORE_ADDR) LM_ADDR (so);
}
- ALL_OBJFILES (so->objfile)
{
! if (strcmp (so->objfile->name, so->so_name) == 0)
! return 1;
! }
! section_addrs.text_addr = text_addr;
! so->objfile =
! symbol_file_add (so->so_name, so->from_tty,
! §ion_addrs, 0, OBJF_SHARED);
! return (1);
! }
! /* This function will check the so name to see if matches the main list.
! In some system the main object is in the list, which we want to exclude */
!
! static int
! match_main (soname)
! char *soname;
! {
! char **mainp;
! for (mainp = main_name_list; *mainp != NULL; mainp++)
! {
! if (strcmp (soname, *mainp) == 0)
! return (1);
! }
! return (0);
}
- /*
! GLOBAL FUNCTION
! solib_add -- add a shared library file to the symtab and section list
SYNOPSIS
! void solib_add (char *arg_string, int from_tty,
! struct target_ops *target)
DESCRIPTION
! */
void
! solib_add (arg_string, from_tty, target)
! char *arg_string;
! int from_tty;
! struct target_ops *target;
{
! register struct so_list *so = NULL; /* link map state variable */
!
! /* Last shared library that we read. */
! struct so_list *so_last = NULL;
! char *re_err;
! int count;
! int old;
#ifdef SVR4_SHARED_LIBS
/* If we are attaching to a running process for which we
--- 1172,1235 ----
+ (CORE_ADDR) LM_ADDR (so);
}
{
! struct section_addr_info section_addrs;
! memset (§ion_addrs, 0, sizeof (section_addrs));
! section_addrs.text_addr = text_addr;
! so->objfile = symbol_file_add (so->so_name, so->from_tty,
! §ion_addrs, 0, OBJF_SHARED);
! }
! return (1);
}
! /* LOCAL FUNCTION
! solib_add -- synchronize GDB's shared object list with the inferior's
SYNOPSIS
! void solib_add (char *pattern, int from_tty, struct target_ops *TARGET)
DESCRIPTION
! Extract the list of currently loaded shared objects from the
! inferior, and compare it with the list of shared objects for which
! GDB has currently loaded symbolic information. If new shared
! objects have been loaded, or old shared objects have disappeared,
! make the appropriate changes to GDB's tables.
!
! If PATTERN is non-null, read symbols only for shared objects
! whose names match PATTERN.
!
! If FROM_TTY is non-null, feel free to print messages about what
! we're doing.
!
! If TARGET is non-null, add the sections of all new shared objects
! to TARGET's section table. Note that this doesn't remove any
! sections for shared objects that have been unloaded, and it
! doesn't check to see if the new shared objects are already present in
! the section table. But we only use this for core files and
! processes we've just attached to, so that's okay. */
void
! solib_add (char *pattern, int from_tty, struct target_ops *target)
{
! struct so_list *inferior = current_sos ();
! struct so_list *gdb, **gdb_link;
! #define JIMB_DEBUG
! #ifdef JIMB_DEBUG
! printf ("GDB's shared library list:\n");
! for (gdb = so_list_head; gdb; gdb = gdb->next)
! printf (" %s\n", gdb->so_original_name);
! printf ("inferior's shared library list:\n");
! for (gdb = inferior; gdb; gdb = gdb->next)
! printf (" %s\n", gdb->so_original_name);
! #endif
#ifdef SVR4_SHARED_LIBS
/* If we are attaching to a running process for which we
***************
*** 1176,1254 ****
#endif SVR4_SHARED_LIBS
! if ((re_err = re_comp (arg_string? arg_string : ".")) != NULL)
{
! error ("Invalid regexp: %s", re_err);
}
! /* Add the shared library sections to the section table of the
! specified target, if any. */
! if (target)
{
! /* Count how many new section_table entries there are. */
! so = NULL;
! count = 0;
! while ((so = find_solib (so)) != NULL)
{
! if (so->so_name[0] && !match_main (so->so_name))
! {
! count += so->sections_end - so->sections;
! }
}
! if (count)
{
!
! /* Add these section table entries to the target's table. */
! old = target_resize_to_sections (target, count);
! while ((so = find_solib (so)) != NULL)
! {
! if (so->so_name[0])
! {
! count = so->sections_end - so->sections;
! memcpy ((char *) (target->to_sections + old),
! so->sections,
! (sizeof (struct section_table)) * count);
! old += count;
! }
! }
}
}
! /* Now add the symbol files. */
! while ((so = find_solib (so)) != NULL)
{
! if (so->so_name[0] && re_exec (so->so_name) &&
! !match_main (so->so_name))
{
! so->from_tty = from_tty;
! if (so->symbols_loaded)
{
! if (from_tty)
{
! printf_unfiltered ("Symbols already loaded for %s\n", so->so_name);
}
}
! else if (catch_errors
! (symbol_add_stub, so,
! "Error while reading shared library symbols:\n",
! RETURN_MASK_ALL))
{
! so_last = so;
! so->symbols_loaded = 1;
}
}
- }
! /* Getting new symbols may change our opinion about what is
! frameless. */
! if (so_last)
! reinit_frame_cache ();
! if (so_last)
! special_symbol_handling (so_last);
}
/*
LOCAL FUNCTION
--- 1243,1417 ----
#endif SVR4_SHARED_LIBS
! if (pattern)
{
! char *re_err = re_comp (pattern);
!
! if (re_err)
! error ("Invalid regexp: %s", re_err);
}
! /* Since this function might actually add some elements to the
! so_list_head list, arrange for it to be cleaned up when
! appropriate. */
! if (!solib_cleanup_queued)
{
! make_run_cleanup (do_clear_solib, NULL);
! solib_cleanup_queued = 1;
! }
!
! /* GDB and the inferior's dynamic linker each maintain their own
! list of currently loaded shared objects; we want to bring the
! former in sync with the latter. Scan both lists, seeing which
! shared objects appear where. There are three cases:
!
! - A shared object appears on both lists. This means that GDB
! knows about it already, and it's still loaded in the inferior.
! Nothing needs to happen.
!
! - A shared object appears only on GDB's list. This means that
! the inferior has unloaded it. We should remove the shared
! object from GDB's tables.
!
! - A shared object appears only on the inferior's list. This
! means that it's just been loaded. We should add it to GDB's
! tables.
!
! So we walk GDB's list, checking each entry to see if it appears
! in the inferior's list too. If it does, no action is needed, and
! we remove it from the inferior's list. If it doesn't, the
! inferior has unloaded it, and we remove it from GDB's list. By
! the time we're done walking GDB's list, the inferior's list
! contains only the new shared objects, which we then add. */
!
! gdb = so_list_head;
! gdb_link = &so_list_head;
! while (gdb)
! {
! struct so_list *i = inferior;
! struct so_list **i_link = &inferior;
!
! /* Check to see whether the shared object *gdb also appears in
! the inferior's current list. */
! while (i)
{
! if (! strcmp (gdb->so_original_name, i->so_original_name))
! break;
!
! i_link = &i->next;
! i = *i_link;
! }
!
! /* If the shared object appears on the inferior's list too, then
! it's still loaded, so we don't need to do anything. Delete
! it from the inferior's list, and leave it on GDB's list. */
! if (i)
! {
! *i_link = i->next;
! #ifdef JIMB_DEBUG
! printf ("unchanged: %s\n", i->so_name);
! #endif
! free_so (i);
! gdb_link = &gdb->next;
! gdb = *gdb_link;
}
! /* If it's not on the inferior's list, remove it from GDB's tables. */
! else
{
! *gdb_link = gdb->next;
! #ifdef JIMB_DEBUG
! printf ("unloaded: %s\n", gdb->so_name);
! #endif
! free_so (gdb);
! gdb = *gdb_link;
}
}
! /* Now the inferior's list contains only shared objects that don't
! appear in GDB's list --- those that are newly loaded. Add them
! to GDB's shared object list, and read in their symbols, if
! appropriate. */
! if (inferior)
{
! struct so_list *i;
!
! /* Add the new shared objects to GDB's list. */
! *gdb_link = inferior;
!
! /* Fill in the rest of each of the `struct so_list' nodes, and
! read symbols for those files whose names match PATTERN. */
! for (i = inferior; i; i = i->next)
{
! i->from_tty = from_tty;
!
! /* Fill in the rest of the `struct so_list' node. */
! catch_errors (solib_map_sections, i,
! "Error while mapping shared library sections:\n",
! RETURN_MASK_ALL);
!
! if (! pattern || re_exec (i->so_name))
{
! if (i->symbols_loaded)
! {
! if (from_tty)
! printf_unfiltered ("Symbols already loaded for %s\n",
! i->so_name);
! }
! else
{
! #ifdef JIMB_DEBUG
! printf ("loaded: %s\n", i->so_name);
! #endif
! if (catch_errors
! (symbol_add_stub, i,
! "Error while reading shared library symbols:\n",
! RETURN_MASK_ALL))
! {
! if (from_tty)
! printf_unfiltered ("Loaded symbols for %s\n",
! i->so_name);
! i->symbols_loaded = 1;
! }
}
}
! }
!
! /* If requested, add the shared objects' sections to the the
! TARGET's section table. */
! if (target)
! {
! int new_sections;
!
! /* Figure out how many sections we'll need to add in total. */
! new_sections = 0;
! for (i = inferior; i; i = i->next)
! new_sections += (i->sections_end - i->sections);
!
! if (new_sections > 0)
{
! int space = target_resize_to_sections (target, new_sections);
!
! for (i = inferior; i; i = i->next)
! {
! int count = (i->sections_end - i->sections);
! memcpy (target->to_sections + space,
! i->sections,
! count * sizeof (i->sections[0]));
! space += count;
! }
}
}
! /* Getting new symbols may change our opinion about what is
! frameless. */
! reinit_frame_cache ();
! special_symbol_handling ();
! }
}
+
/*
LOCAL FUNCTION
***************
*** 1289,1295 ****
addr_fmt = "016l";
#endif
! while ((so = find_solib (so)) != NULL)
{
if (so->so_name[0])
{
--- 1452,1460 ----
addr_fmt = "016l";
#endif
! solib_add (0, 0, 0);
!
! for (so = so_list_head; so; so = so->next)
{
if (so->so_name[0])
{
***************
*** 1347,1361 ****
{
register struct so_list *so = 0; /* link map state variable */
! while ((so = find_solib (so)) != NULL)
{
! if (so->so_name[0])
! {
! if ((address >= (CORE_ADDR) LM_ADDR (so)) &&
! (address < (CORE_ADDR) so->lmend))
! return (so->so_name);
! }
}
return (0);
}
--- 1512,1524 ----
{
register struct so_list *so = 0; /* link map state variable */
! for (so = so_list_head; so; so = so->next)
{
! if ((address >= (CORE_ADDR) LM_ADDR (so)) &&
! (address < (CORE_ADDR) so->lmend))
! return (so->so_name);
}
+
return (0);
}
***************
*** 1775,1781 ****
{
/* If we are using the BKPT_AT_SYMBOL code, then we don't need the base
yet. In fact, in the case of a SunOS4 executable being run on
! Solaris, we can't get it yet. find_solib will get it when it needs
it. */
#if !(defined (SVR4_SHARED_LIBS) && defined (BKPT_AT_SYMBOL))
if ((debug_base = locate_base ()) == 0)
--- 1938,1944 ----
{
/* If we are using the BKPT_AT_SYMBOL code, then we don't need the base
yet. In fact, in the case of a SunOS4 executable being run on
! Solaris, we can't get it yet. current_sos will get it when it needs
it. */
#if !(defined (SVR4_SHARED_LIBS) && defined (BKPT_AT_SYMBOL))
if ((debug_base = locate_base ()) == 0)
***************
*** 1843,1849 ****
SYNOPSIS
! void special_symbol_handling (struct so_list *so)
DESCRIPTION
--- 2006,2012 ----
SYNOPSIS
! void special_symbol_handling ()
DESCRIPTION
***************
*** 1859,1866 ****
*/
static void
! special_symbol_handling (so)
! struct so_list *so;
{
#ifndef SVR4_SHARED_LIBS
int j;
--- 2022,2028 ----
*/
static void
! special_symbol_handling ()
{
#ifndef SVR4_SHARED_LIBS
int j;
From guo@cup.hp.com Sat Apr 01 00:00:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: "Daniel Berlin+mail.gdb" <dan@cgsoftware.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: RTTI working for G++
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <Pine.LNX.4.10.10003161724440.4096-100000@hpcll168.cup.hp.com>
References: <Pine.LNX.4.10.10003161127110.4096-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-q1/msg00727.html
Content-length: 610
A general question about the repositories on sourceware:
Can we use cvsup client tool to maintain a local repository? Instead of
getting 'snapshots' via the CVS interfaces, I'd like to use the cvsup
tool to get updates to the repositories. It requires sourceware to run
a cvsupd daemon.
Otherwise, what is the easiest way to maintain local repository? I want
to create a local repository containing gdb, dejagnu, and binutils
products, and be able to automatically 'synchronize' with sourceware's
every night or on demand (turn-key solution here).
Thanks for any suggestion!
- Jimmy Guo, guo@cup.hp.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Regressions problem (200 failures)
[not found] ` <200003021143.MAA14294@reisser.regent.e-technik.tu-muenchen.de>
@ 2000-03-02 8:56 ` Mark Mitchell
0 siblings, 0 replies; 7+ messages in thread
From: Mark Mitchell @ 2000-03-02 8:56 UTC (permalink / raw)
To: Peter.Schauer; +Cc: kingdon, donnte, gdb
>>>>> "Peter" == Peter Schauer <Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE> writes:
Peter> with GCC or GDB), a breakpoint on the opening brace is not
Peter> what I want, as I will almost always have to step over it.
Peter> I'd expect a breakpoint on the first local variable that
Peter> needs initalization, or the first statement.
Yes, I think we're all agreed.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
From mark@codesourcery.com Thu Mar 02 08:59:00 2000
From: Mark Mitchell <mark@codesourcery.com>
To: kettenis@wins.uva.nl
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 08:59:00 -0000
Message-id: <20000302090701N.mitchell@codesourcery.com>
References: <200003021010.LAA13693@reisser.regent.e-technik.tu-muenchen.de> <20000302023420H.mitchell@codesourcery.com> <200003021246.e22CkWL00549@delius.kettenis.local>
X-SW-Source: 2000-03/msg00047.html
Content-length: 937
>>>>> "Mark" == Mark Kettenis <kettenis@wins.uva.nl> writes:
Mark> some bit rot since then. Are the prologue's generated by
Mark> GCC any different from those generated back in 1994?
I dunno, but my guess is that's not the bug.
Right now, the problem is:
o We put line notes in the prologue
o We weren't putting line notes before the first real code, so
GCC was skipping over that too.
o I promoted the last line note in the prologue to appear before
the first real code, bringing GCC back to seme-sensible behavior.
We could try to:
o Not emit line notes in the prologue that correspond to the '{'
line.
o Try to find the first line note in the real code, instead of
the last line note in the prologue.
The latter is probably easiest, but is still harder that what I did.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
From gzp@gzp.org.hu Thu Mar 02 11:48:00 2000
From: "Gabor Z. Papp" <gzp@gzp.org.hu>
To: gdb@sourceware.cygnus.com
Subject: gdb cvs
Date: Thu, 02 Mar 2000 11:48:00 -0000
Message-id: <20000302204824.B18856@gzp.org.hu>
References: <200003021924.e22JO4U19747@mail.gzp.org.hu>
X-SW-Source: 2000-03/msg00048.html
Content-length: 5091
| cvs server: Updating gdb
| U gdb/CONTRIBUTE
[...]
| U gdb/vx-share/xdr_rdb.h
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/texinfo
| cvs server: ignoring module src/texinfo
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/bfd
| cvs server: ignoring module src/bfd
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/opcodes
| cvs server: ignoring module src/opcodes
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/readline
| cvs server: ignoring module src/readline
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/libiberty
| cvs server: ignoring module src/libiberty
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/mmalloc
| cvs server: ignoring module src/mmalloc
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/include
| cvs server: ignoring module src/include
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/sim
| cvs server: ignoring module src/sim
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/utils
| cvs server: ignoring module src/utils
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/.cvsignore
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/COPYING
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/COPYING.LIB
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/ChangeLog
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/Makefile.in
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/README
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/config
| cvs server: ignoring module src/config
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/config-ml.in
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/config.guess
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/config.if
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/config.sub
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/configure
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/configure.in
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/etc
| cvs server: ignoring module src/etc
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/install-sh
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/ltconfig
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/ltmain.sh
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/makefile.vms
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/missing
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mkdep
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mkinstalldirs
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/move-if-change
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mpw-README
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mpw-build.in
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mpw-config.in
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mpw-configure
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mpw-install
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/setup.com
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/symlink-tree
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/ylwrap
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/intl
| cvs server: ignoring module src/intl
Is this correct?
From ac131313@cygnus.com Thu Mar 02 16:22: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: Thu, 02 Mar 2000 16:22:00 -0000
Message-id: <38BF0551.9B4FE1E@cygnus.com>
References: <200003021924.e22JO4U19747@mail.gzp.org.hu> <20000302204824.B18856@gzp.org.hu>
X-SW-Source: 2000-03/msg00049.html
Content-length: 299
"Gabor Z. Papp" wrote:
>
> | cvs server: Updating gdb
> | U gdb/CONTRIBUTE
>
> [...]
>
>
> Is this correct?
Were you doing a: ``co gdb'' over the top of an existing tree? I've
encountered that message then.
I suspect it isn't correct but, from what I saw it still did what I
wanted.
Andrew
From muller@cerbere.u-strasbg.fr Fri Mar 03 00:28:00 2000
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com
Subject: RFD: New command to inspect other selectors memory.
Date: Fri, 03 Mar 2000 00:28:00 -0000
Message-id: <200003030843.JAA12246@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/msg00050.html
Content-length: 1161
I inserted this in a reply about pascal extension, but as I got no answer,
I thought
I will send it as a separate message.
I have written for DJGPP target a relatively small patch.
It allows to read memory from another selector
this was very useful for me when I tried to debug the debugger itself and
when I added exception support fro GDB on DJGPP !
This patch consists of the addition of one command that I called "xx"
which is a simple clone of the "x" command but can take a selector
as for intance
"xx $fs:0x400"
then the next "xx 0x800" keeps using the last selector value.
I do not know if this could be interesting for other i386 targets
(maybe for win32 to be able to see the content of the $fs selector
that contains the exception chain, but I am not sure how if its
readable inside a win32 API program).
Is such kind of patch too specific to have any chance to get accepted ?
I don't know if it could be of any use for other processors or operating
system !!
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 ac131313@cygnus.com Fri Mar 03 00:56:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: tromey@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: 5.0 known issues 2000-02-16
Date: Fri, 03 Mar 2000 00:56:00 -0000
Message-id: <38BF7E1D.4E0A904D@cygnus.com>
References: <38AA42EA.5106E153@cygnus.com> <87ael1ynl8.fsf@cygnus.com>
X-SW-Source: 2000-03/msg00051.html
Content-length: 354
Tom Tromey wrote:
>
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>
> Andrew> GNU/Linux/i386:
>
> Without my patch, gdb doesn't work at all when run on x86 Linux boxes
> with older kernels (I still run 2.0.34).
Tom,
I belive JimB's bubbled this up to the top of his queue and made it one
of the things try to get into 5.0
Andrew
From ac131313@cygnus.com Fri Mar 03 01:16:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jimmy Guo <guo@cup.hp.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: 5.0 known issues 2000-02-16
Date: Fri, 03 Mar 2000 01:16:00 -0000
Message-id: <38BF81BD.C7C35B59@cygnus.com>
References: <Pine.LNX.4.10.10002161044530.25408-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-03/msg00052.html
Content-length: 699
Jimmy Guo wrote:
>
> >HP/UX: Unfortunately this was knocked about pretty badly by the move to
> >an external repository (sorry). Jimmy's looking at it along with Jason
> >and (possibly) Jeff (shared lib problem). I'm also going to try get
> >access to a HPUX box and give it a whirl.
>
> Provided that Jeff has applied the changes (include/hp-symtab.h) into
> the public repository, GDB should build for HP targets.
>
> Currently we're still relying on weekly snapshots to pick up updates. I
> know this would have to change for us to access CVS directly ... once
> there's a snapshot I will see if it is fixed ...
Just FYI, Hopefully the weekly snapshots are starting to flow again.
Andrew
From insulaner_andi@yahoo.com Fri Mar 03 02:18:00 2000
From: Andreas Kuepper <insulaner_andi@yahoo.com>
To: gdb@sourceware.cygnus.com
Subject: running GDB on Cygwin
Date: Fri, 03 Mar 2000 02:18:00 -0000
Message-id: <20000303101528.22003.qmail@web3402.mail.yahoo.com>
X-SW-Source: 2000-03/msg00053.html
Content-length: 364
Is there anybody who ever tried to run GDB on Cygwin?
I want to do remote debugging and when I run
"configure" it fails with the message :
configure: error: could not find term library
Thanks for your help!
Andreas Kuepper
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
From kettenis@wins.uva.nl Fri Mar 03 04:40:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: muller@cerbere.u-strasbg.fr
Cc: gdb@sourceware.cygnus.com
Subject: Re: RFD: New command to inspect other selectors memory.
Date: Fri, 03 Mar 2000 04:40:00 -0000
Message-id: <200003031240.e23CeRn00162@delius.kettenis.local>
References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003030843.JAA12246@cerbere.u-strasbg.fr>
X-SW-Source: 2000-03/msg00054.html
Content-length: 1571
Date: Fri, 03 Mar 2000 09:27:14 +0100
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
I inserted this in a reply about pascal extension, but as I got no answer,
I thought
I will send it as a separate message.
Sorry about that.
I have written for DJGPP target a relatively small patch.
It allows to read memory from another selector
this was very useful for me when I tried to debug the debugger itself and
when I added exception support fro GDB on DJGPP !
This patch consists of the addition of one command that I called "xx"
which is a simple clone of the "x" command but can take a selector
as for intance
"xx $fs:0x400"
then the next "xx 0x800" keeps using the last selector value.
I do not know if this could be interesting for other i386 targets
(maybe for win32 to be able to see the content of the $fs selector
that contains the exception chain, but I am not sure how if its
readable inside a win32 API program).
Is such kind of patch too specific to have any chance to get accepted ?
I don't know if it could be of any use for other processors or operating
system !!
This may be impossible to implement on most i386 targets (with the
possible exception of Solaris and Mach-based targets), but nevrtheless
it could be useful to have for things that are a bit more low-level
(like debugging a threads library that uses segmentation to store
per-thread data and such). The suggested syntax could probably be
improved, since "xx" isn't very descriptive. People with bright ideas?
Mark
From ac131313@cygnus.com Fri Mar 03 04:52: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: RFD: New command to inspect other selectors memory.
Date: Fri, 03 Mar 2000 04:52:00 -0000
Message-id: <38BFB50A.606036CF@cygnus.com>
References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003030843.JAA12246@cerbere.u-strasbg.fr>
X-SW-Source: 2000-03/msg00055.html
Content-length: 1420
Pierre Muller wrote:
>
> I inserted this in a reply about pascal extension, but as I got no answer,
> I thought
> I will send it as a separate message.
>
> I have written for DJGPP target a relatively small patch.
> It allows to read memory from another selector
> this was very useful for me when I tried to debug the debugger itself and
> when I added exception support fro GDB on DJGPP !
>
> This patch consists of the addition of one command that I called "xx"
> which is a simple clone of the "x" command but can take a selector
> as for intance
> "xx $fs:0x400"
> then the next "xx 0x800" keeps using the last selector value.
> I do not know if this could be interesting for other i386 targets
> (maybe for win32 to be able to see the content of the $fs selector
> that contains the exception chain, but I am not sure how if its
> readable inside a win32 API program).
>
> Is such kind of patch too specific to have any chance to get accepted ?
> I don't know if it could be of any use for other processors or operating
> system !!
I'm not sure what the x86 people will do.
However the generic problem of getting GDB to understand segments is one
of those things that has long sat on peoples wishlists.
The theory is that if ``CORE_ADDR'' is made in to a pretend object
(ISO-C remember :-) and then the rest falls out.... As they say, the
proof is left as an exercise to the reader.
enjoy,
Andrew
From muller@cerbere.u-strasbg.fr Fri Mar 03 06:47:00 2000
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: gdb@sourceware.cygnus.com
Subject: 2 pascal language patches inserted in database
Date: Fri, 03 Mar 2000 06:47:00 -0000
Message-id: <200003031500.QAA18276@cerbere.u-strasbg.fr>
References: <200003021452.PAA02334@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr>
X-SW-Source: 2000-03/msg00056.html
Content-length: 423
I submitted two patches for pascal extension in the database!
I am subscribed to gdb-patches and I think that this should be enough to
gt also
all mails generated by the gdb patch database, but I saw a
subcribe link! Why is this distinct ?
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 hjl@lucon.org Fri Mar 03 07:17:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: tromey@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: 5.0 known issues 2000-02-16
Date: Fri, 03 Mar 2000 07:17:00 -0000
Message-id: <20000303071729.B31569@lucon.org>
References: <38AA42EA.5106E153@cygnus.com> <87ael1ynl8.fsf@cygnus.com> <38BF7E1D.4E0A904D@cygnus.com>
X-SW-Source: 2000-03/msg00057.html
Content-length: 705
On Fri, Mar 03, 2000 at 07:55:57PM +1100, Andrew Cagney wrote:
> Tom Tromey wrote:
> >
> > >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> >
> > Andrew> GNU/Linux/i386:
> >
> > Without my patch, gdb doesn't work at all when run on x86 Linux boxes
> > with older kernels (I still run 2.0.34).
>
> Tom,
>
> I belive JimB's bubbled this up to the top of his queue and made it one
> of the things try to get into 5.0
FWIW, the static gdb binary of gdb 4.17.0.1x compiled with glibc 2.1
and kernel 2.2 works on kernel >= 2.0, libc 5, glibc 2.0 and glibc
2.1. It should also work on glibc 2.2. Kernel and libc are detected at
the runtime. It will be nice that 5.0 can do the same.
H.J.
From kettenis@wins.uva.nl Fri Mar 03 07:31:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: `long double' support for ix86 targets
Date: Fri, 03 Mar 2000 07:31:00 -0000
Message-id: <200003031531.e23FV8T00285@delius.kettenis.local>
X-SW-Source: 2000-03/msg00058.html
Content-length: 5450
Hi,
Kevin's changes to findvar.c:extract_floating() and store_floating()
together with some further analysis have convinced me that for all but
one ix86 targets 96-bit long doubles of type &floatformat_i387_ext are
the right thing. This would give most of the ix86 targets instant
support for long doubles. It also gives us the opportunity to remove
some ugly bits introduced by people who tried to hack around the
current limitations.
Here are some personal notes I made about this:
Support for `long double'
-------------------------
The majority of i386 targets in GCC have a `long double' that is
96 bits wide (of which only 80 bits are used, the rest is padding).
In fact the only exception is OSF/1, where `long double' is equivalent
to `double' and has only 64 bits. This length of 96 bits is also
used in the debugging information generated by the compiler.
The origional i386 System V ABI specification doesn't say anything about
`long double', but the new (draft) IA-64 System V ABI specification
uses a `long double' of 96 bits for things running in 32-bit mode.
I guess that 32-bit mode is supposed to be provided for compatible
with IA-32, this implies that 96 bits is supposed to be the standard.
Therefore, `config/i386/tm-i386.h' should define:
#define TARGET_LONG_DOUBLE_FORMAT &floatformat_i387_ext
#define TARGET_LONG_DOUBLE_BITS 96
Targets such as OSF/1 can override this.
If we do the above, we can make the default "virtual" type of the FPU
registers `builtin_type_long_double'. A lot of the Linux cruft for
dealing with `long double' could be removed.
I intend to check in the following patch in a week or two, but since
this change affects most of the ix86 targets, I'd like to give people
the opportunity to object.
Mark
2000-03-02 Mark Kettenis <kettenis@gnu.org>
* config/i386/tm-i386.h (TARGET_LONG_DOUBLE_FORMAT): Define as
&floatformat_i387_ext.
(TARGET_LONG_DOUBLE_BITS): Define as 96.
(REGISTER_VIRTUAL_TYPE): Change type for FPU registers to
`builtin_type_long_double'.
(REGISTER_CONVERT_TO_VIRTUAL): Simply copy over the data, and pad
with zeroes.
(REGISTER_CONVERT_TO_RAW): Simply copy over the significant data.
(i387_to_double, double_to_i387): Remove prototypes.
Index: config/i386/tm-i386.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-i386.h,v
retrieving revision 1.2
diff -u -p -r1.2 tm-i386.h
--- config/i386/tm-i386.h 2000/02/29 13:28:24 1.2
+++ config/i386/tm-i386.h 2000/03/03 15:00:49
@@ -1,5 +1,5 @@
/* Macro definitions for GDB on an Intel i[345]86.
- Copyright (C) 1995, 1996 Free Software Foundation, Inc.
+ Copyright (C) 1995, 1996, 2000 Free Software Foundation, Inc.
This file is part of GDB.
@@ -28,6 +28,19 @@ struct type;
#define TARGET_BYTE_ORDER LITTLE_ENDIAN
+/* The format used for `long double' on almost all i386 targets is the
+ i387 extended floating-point format. In fact, of all targets in the
+ GCC 2.95 tree, only OSF/1 does it different, and insists on having
+ a `long double' that's not `long' at all. */
+
+#define TARGET_LONG_DOUBLE_FORMAT &floatformat_i387_ext
+
+/* Although the i386 extended floating-point has only 80 significant
+ bits, a `long double' actually takes up 96, probably to enforce
+ alignment. */
+
+#define TARGET_LONG_DOUBLE_BITS 96
+
/* Used for example in valprint.c:print_floating() to enable checking
for NaN's */
@@ -229,7 +242,7 @@ extern int i386_register_virtual_size[];
#define REGISTER_VIRTUAL_TYPE(N) \
(((N) == PC_REGNUM || (N) == FP_REGNUM || (N) == SP_REGNUM) \
? lookup_pointer_type (builtin_type_void) \
- : IS_FP_REGNUM(N) ? builtin_type_double \
+ : IS_FP_REGNUM(N) ? builtin_type_long_double \
: IS_SSE_REGNUM(N) ? builtin_type_v4sf \
: builtin_type_int)
@@ -239,25 +252,22 @@ extern int i386_register_virtual_size[];
that SSE registers need conversion. Even if we can't find a
counterexample, this is still sloppy. */
#define REGISTER_CONVERTIBLE(n) (IS_FP_REGNUM (n))
-
-/* Convert data from raw format for register REGNUM in buffer FROM
- to virtual format with type TYPE in buffer TO. */
-extern void i387_to_double (char *, char *);
+/* Convert data from raw format for register REGNUM in buffer FROM to
+ virtual format with type TYPE in buffer TO. In principle both
+ formats are identical except that the virtual format has two extra
+ bytes appended that aren't used. We set these to zero. */
#define REGISTER_CONVERT_TO_VIRTUAL(REGNUM,TYPE,FROM,TO) \
-{ \
- double val; \
- i387_to_double ((FROM), (char *)&val); \
- store_floating ((TO), TYPE_LENGTH (TYPE), val); \
-}
-
-extern void double_to_i387 (char *, char *);
-
-#define REGISTER_CONVERT_TO_RAW(TYPE,REGNUM,FROM,TO) \
-{ \
- double val = extract_floating ((FROM), TYPE_LENGTH (TYPE)); \
- double_to_i387((char *)&val, (TO)); \
-}
+ { \
+ memset ((TO), 0, TYPE_LENGTH (TYPE)); \
+ memcpy ((TO), (FROM), FPU_REG_RAW_SIZE); \
+ }
+
+/* Convert data from virtual format with type TYPE in buffer FROM to
+ raw format for register REGNUM in buffer TO. Simply omit the two
+ unused bytes. */
+#define REGISTER_CONVERT_TO_RAW(TYPE,REGNUM,FROM,TO) \
+ memcpy ((TO), (FROM), FPU_REG_RAW_SIZE)
/* Print out the i387 floating point state. */
#ifdef HAVE_I387_REGS
From ezannoni@cygnus.com Fri Mar 03 07:52:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: PATCH: Eliminate some uses of PTR.
Date: Fri, 03 Mar 2000 07:52:00 -0000
Message-id: <14527.57252.598442.150750@kwikemart.cygnus.com>
X-SW-Source: 2000-03/msg00059.html
Content-length: 4376
This eliminates uses of PTR from event-loop.h, event-top.c.
I've checked this in.
Elena
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.96
diff -c -r1.96 ChangeLog
*** ChangeLog 2000/03/03 02:18:26 1.96
--- ChangeLog 2000/03/03 15:26:44
***************
*** 1,3 ****
--- 1,12 ----
+ 2000-03-03 Elena Zannoni <ezannoni@kwikemart.cygnus.com>
+
+ * defs.h (struct continuation_arg): Change type of field 'data'
+ from PTR to void *.
+
+ * event-loop.h: Eliminate uses of PTR, use 'void *' instead.
+
+ * event-top.c: Ditto.
+
2000-03-02 Elena Zannoni <ezannoni@kwikemart.cygnus.com>
* config/alpha/alpha-linux.mh: Remove core-regset.o fron the
Index: defs.h
===================================================================
RCS file: /cvs/src/src/gdb/defs.h,v
retrieving revision 1.4
diff -c -r1.4 defs.h
*** defs.h 2000/02/24 00:04:03 1.4
--- defs.h 2000/03/03 15:26:44
***************
*** 613,619 ****
struct continuation_arg
{
struct continuation_arg *next;
! PTR data;
};
struct continuation
--- 613,619 ----
struct continuation_arg
{
struct continuation_arg *next;
! void *data;
};
struct continuation
Index: event-loop.h
===================================================================
RCS file: /cvs/src/src/gdb/event-loop.h,v
retrieving revision 1.1.1.15
diff -c -r1.1.1.15 event-loop.h
*** event-loop.h 1999/10/05 23:08:11 1.1.1.15
--- event-loop.h 2000/03/03 15:26:44
***************
*** 57,63 ****
Corollary tasks are the creation and deletion of event sources. */
! typedef PTR gdb_client_data;
struct async_signal_handler;
typedef void (handler_func) (int, gdb_client_data);
typedef void (sig_handler_func) (gdb_client_data);
--- 57,63 ----
Corollary tasks are the creation and deletion of event sources. */
! typedef void * gdb_client_data;
struct async_signal_handler;
typedef void (handler_func) (int, gdb_client_data);
typedef void (sig_handler_func) (gdb_client_data);
Index: event-top.c
===================================================================
RCS file: /cvs/src/src/gdb/event-top.c,v
retrieving revision 1.2
diff -c -r1.2 event-top.c
*** event-top.c 2000/02/23 00:25:42 1.2
--- event-top.c 2000/03/03 15:26:44
***************
*** 129,145 ****
handlers mark these functions as ready to be executed and the event
loop, in a later iteration, calls them. See the function
invoke_async_signal_handler. */
! PTR sigint_token;
#ifdef SIGHUP
! PTR sighup_token;
#endif
! PTR sigquit_token;
! PTR sigfpe_token;
#if defined(SIGWINCH) && defined(SIGWINCH_HANDLER)
! PTR sigwinch_token;
#endif
#ifdef STOP_SIGNAL
! PTR sigtstp_token;
#endif
/* Structure to save a partially entered command. This is used when
--- 129,145 ----
handlers mark these functions as ready to be executed and the event
loop, in a later iteration, calls them. See the function
invoke_async_signal_handler. */
! void *sigint_token;
#ifdef SIGHUP
! void *sighup_token;
#endif
! void *sigquit_token;
! void *sigfpe_token;
#if defined(SIGWINCH) && defined(SIGWINCH_HANDLER)
! void *sigwinch_token;
#endif
#ifdef STOP_SIGNAL
! void *sigtstp_token;
#endif
/* Structure to save a partially entered command. This is used when
***************
*** 525,532 ****
(struct continuation_arg *) xmalloc (sizeof (struct continuation_arg));
arg1->next = arg2;
arg2->next = NULL;
! arg1->data = (PTR) time_at_cmd_start;
! arg2->data = (PTR) space_at_cmd_start;
add_continuation (command_line_handler_continuation, arg1);
}
--- 525,532 ----
(struct continuation_arg *) xmalloc (sizeof (struct continuation_arg));
arg1->next = arg2;
arg2->next = NULL;
! arg1->data = (void *) time_at_cmd_start;
! arg2->data = (void *) space_at_cmd_start;
add_continuation (command_line_handler_continuation, arg1);
}
***************
*** 957,963 ****
}
void
! mark_async_signal_handler_wrapper (PTR token)
{
mark_async_signal_handler ((struct async_signal_handler *) token);
}
--- 957,963 ----
}
void
! mark_async_signal_handler_wrapper (void *token)
{
mark_async_signal_handler ((struct async_signal_handler *) token);
}
From kettenis@wins.uva.nl Fri Mar 03 08:36:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: msnyder@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: lin-thread cannot handle thread exit
Date: Fri, 03 Mar 2000 08:36:00 -0000
Message-id: <200003031635.e23GZwi00372@delius.kettenis.local>
X-SW-Source: 2000-03/msg00060.html
Content-length: 1394
Hi Michael,
The thread_db assisted debugging code doesn't handle exiting threads
properly, at least in combination with glibc 2.1.3. There are at
least two problems that prevent this from working:
1. In lin-thread.c:enable_thread_event_reporting(), GDB requests
TD_DEATH events to be reported, and sets a breakpoint at the
appropriate location. The problem is that the LinuxThreads
implementation included with glibc 2.1.3 triggers that breakpoint
after it has flagged the thread as terminated. As a conseuqence
when GDB tries to fetch the registers for that thread it doesn't
succeed, and GDB complains about a breakpoint at location 0x0 that
it doesn't know of.
2. If I disable the reporting of TD_DEATH events, things still don't
work. The problem is that when the thread really exits, a
TARGET_WAITKIND_EXITED event is reported to GDB in. So the answer to
the question ``Can I get this event mistakenly from a thread?'' in
lin-thread.c:thread_db_wait() is ``Yes''. Since the
TARGET_WAITKIND_EXITED event is passed on to other code in GDB, GDB
thinks that the entire process has died.
Ignoring those "spurious" TARGET_WAITKIND_EXITED events doesn't help
since some parts of GDB still think that the thread is still alive
then.
Looking through the code, it seems that there quite a few "loose
ends". Is this still "work in progress"?
Mark
^ 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-03-01 9:49 Regressions problem (200 failures) Donn Terry
2000-04-01 0:00 ` Donn Terry
[not found] ` <20000301123337B.mitchell@codesourcery.com>
2000-04-01 0:00 ` Jim Kingdon
2000-04-01 0:00 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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox