Re: Problems with GDB-5.0 and recent Linux kernels (2.4.0-test1-ac[47])

Re: Problems with GDB-5.0 and recent Linux kernels (2.4.0-test1-ac[47])

[Mark Kettenis]

[ Apologies to those receiving two copies of this message.  My ISP has
  managed to get one of its mail servers in ORBS again.  Sigh ... ]

   From: Andris Pavenis <pavenis@latnet.lv>
   Date: Sat, 3 Jun 2000 20:37:45 +0200

   Have somebody tried GDB commands 'info float' and 'info reg' on a
   system running latest ac kernels. I'm getting coredump from gdb-5.0
   on these commands.

   2.4.0-test1 - seems that all works, no such problem
   2.4.0-test1-ac4 and 2.4.0-test1-ac7  - gdb coredumps on these commands

   It seems to be some stack corruption.

Smells like a kernel bug to me.  Yep it is!  The Pentium III FXSR, SSE
support breaks changes the ABI of the ptrace(GETFPREGS, ...) interface
in an incompatible way.  The size of `struct user_i387_struct' has been
changed, so the kernel writes beyond the space on the stack reserved
by GDB, hence the stack corruption.

The kernel folks will have to find another way to implement this.
Probably by introducing a new ptrace request.  A while back Jim Blandy
implemented support for the SSE registers in GDB, based on a different
kernel patch that implemented a GETXFPREGS requests.  It also
implements support for core dumps in a different way, using an extra
section for the SSE registers.  Take a look at the GDB 5.0 release, or
the following URL:

  http://sourceware.cygnus.com/cgi-bin/cvsweb.cgi/src/gdb/i386-linux-nat.c?cvsroot=src

It would be great, if the interface in the kernel could be compatible
with Jim's implementation, since that would mean instant support for
the SSE registers in GDB once the glibc headers have been updated.

By the way, I suspect that the change to `struct user_i387_struct'
also change the offset of the u_debugreg member of `struct user', and
therefore will break GDB's support for hardware brea/watchpoints.

Mark
From kevinb@cygnus.com Sat Jun 03 15:42:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Proposal: convert function definitions to prototyped form
Date: Sat, 03 Jun 2000 15:42:00 -0000
Message-id: <1000603224224.ZM1091@ocotillo.lan>
References: <200006021539.LAA25912@texas.cygnus.com> <1000602191042.ZM30936@ocotillo.lan> <200006031058.GAA12885@indy.delorie.com> <1000603175039.ZM738@ocotillo.lan> <200006031837.OAA13278@indy.delorie.com> <eliz@delorie.com>
X-SW-Source: 2000-06/msg00038.html
Content-length: 1444

On Jun 3,  2:37pm, Eli Zaretskii wrote:

> > Date: Sat, 3 Jun 2000 10:50:39 -0700
> > From: Kevin Buettner <kevinb@cygnus.com>
> >
> > That's why I wrote check-decls (see 
> >     http://sourceware.cygnus.com/ml/gdb/2000-06/msg00028.html
> > ) which takes the result of comparing (via diff -u) the original
> > sources with the protoized sources and produces a C source file in
> > which the portions from the protoized sources are used to construct
> > prototypes and the portions from the original sources are used to
> > construct (potentially?) corresponding function definitions.  We can
> > then invoke the C compiler (gcc -c -Wall) on the result and see what
> > kinds of warnings and errors are produced.
> 
> I saw that script, but I don't like the idea to depend on a human to
> judge what GCC warnings are okay to ignore and what aren't.  I'd
> prefer an automated tool that would give a definite yes/no answer, if
> that's possible.

I see your point.

If I do as Andrew suggests and prevent fix-decls from looking at the
*-share directories, that will prevent the arg_type conflict which
is responsible for the errors.  That leaves only the exit() warning
from standalone.c to worry about.  I can probably devise a solution
which will prevent that warning from occurring as well.

Anyway... I will see if I can arrange it so that any error or warning
indicates a problem and no errors or warnings indicates that all's
well.

Kevin
From ac131313@cygnus.com Sat Jun 03 18:18:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Eli Zaretskii <eliz@is.elta.co.il>, gdb@sourceware.cygnus.com
Subject: Re: Proposal: convert function definitions to prototyped form
Date: Sat, 03 Jun 2000 18:18:00 -0000
Message-id: <3939AE2C.BD44873A@cygnus.com>
References: <200006021539.LAA25912@texas.cygnus.com> <1000602191042.ZM30936@ocotillo.lan> <200006031058.GAA12885@indy.delorie.com> <1000603175039.ZM738@ocotillo.lan>
X-SW-Source: 2000-06/msg00039.html
Content-length: 1012

Kevin Buettner wrote:
> 
> On Jun 3,  6:58am, Eli Zaretskii wrote:
> 
> > So with a script, we will always need a verification tool that can be
> > trusted to find any potential bugs introduced by reformatting.
> 
> Right.
> 
> That's why I wrote check-decls (see
>     http://sourceware.cygnus.com/ml/gdb/2000-06/msg00028.html
> ) which takes the result of comparing (via diff -u) the original
> sources with the protoized sources and produces a C source file in
> which the portions from the protoized sources are used to construct
> prototypes and the portions from the original sources are used to
> construct (potentially?) corresponding function definitions.  We can
> then invoke the C compiler (gcc -c -Wall) on the result and see what
> kinds of warnings and errors are produced.

Rather than -Wall (badly missnamed) I'd suggest several more carefully
selected flags such as: -Wimplict -Wreturn-type -Wstrict-prototypes
-Wmissing-declarations.  No need to make life difficult for your self
:-)

	Andrew
From ac131313@cygnus.com Sun Jun 04 19:57:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: 5.0 post mortem
Date: Sun, 04 Jun 2000 19:57:00 -0000
Message-id: <393B16D9.E217DAA1@cygnus.com>
X-SW-Source: 2000-06/msg00040.html
Content-length: 4058

(FWIW, I don't know what happened to the gnu.announce posting - I
definitly submitted it :-)

Well before a 5.0.1 or 5.1 release is started its probably worth having
a bit of a post-mortem (where the vultures can pick over the bones of
what happened :-)  Here are my random thoughts:


	o	feature based not date based release criteria

		First lesson I learnt was that people don't
		like releases made on the basis of an arbitrary
		date.

		Instead the consensus was that a set of features
		should be identified and the release should be
		made once those features were included.

		In the end there was some give and take over
		what was in/out of the list.  Given the size
		of the backlog from the previous release I think
		what we ended up with was pretty reasonable.
		Things that were dropped were either dropped
		because they had no active developer or because
		the problem was too difficult/complex for the
		expected time frame.


	o	must have VS nice to have VS won't have

\x12		Once consequence of the first point was that
		I ended up maintaining (using the TODO file!)
		three separate lists.

		In doing this, I tried to avoid the situtation
		where people were only allowed to work on
		``must have items''.  If I had tried to do that
		I think development would have simply stagnated.
		Instead I tried to categorize the feature list
		based on those three criteria.  They would then
		be moved depending on what I perceved as the
		current reality.  I figured ``must have'' wasn't
		much use if no one was willing to work on it.
		Besides, if someone implemented a ``might have''
		or ``won't have'' who am I to argue :-)

		I tried to apply the ``won't have'' where I felt
		that there was more benefit in getting the work
		into the follow on release than trying to squeeze
		it into the current release.  As a category,
		``won't have'' is only going to work if there are
		regular releases and people can build up confidence
		in it.

		I don't know what people think of me using the TODO
		list as the tracking mechanism.  I also don't
		know what people thought of my fairly abitrary
		(at times) re-aranging of the three lists.


	o	I need to remember to use the gdb-testers mailing list

		When putting up release candidates I need to
		remember to post them to gdb-testers (which
		has a different audience to gdb-patches and
		the like).  On more than one occasion I simply
		forgot.


	o	A better way of tracking test results

		I tried using the TODO file for that however
		I don't think it was very successful.  Having
		public test farms like netwinder.org are probably
		a step in the right direction. (I just wish they
		would include the test results on the main page
		so I didn't have to download that summary.log :-)

		I'm fairly skeptical towards idea's that involve
		people maintaining pages by hand.


	o	I think the branch timing was about right

		Comparing the changes made to the trunk/branch,
		I think, in the end, the 5.0 branch was
		cut at about the right time.

		The emphasis was on getting the 5.0 feature
		list resolved (fixed or discarded) and then
		cutting the branch.


	o	we need more tests

		The old perennial.  There are never too many
		tests.

		My personal opinion is that, once the branch,
		has been cut it is almost too late to try
		to fix bugs the test suite is identifying.
		Instead they should be documented.  The emphasis
		should instead be put on keeping the trunk
		in good condition so it can be branched at
		any time.


	o	give that final release candidate ~7 days

		For those that don't know, I received
		e-mail of a djgpp problem just after I'd
		put the final release on sourceware but
		before gnu.org.


	o	ftp.gnu.org is first not last

		Following on from the above, get the
		final release candidate onto ftp.gnu.org
		first not last.  That way the cut off date
		is extended.


	o	the mechanics worked

		The mechanical process of spinning a release
		worked without a hitch - the nightly build is
		using it (and hence testing it).

nice day for it,

	Andrew
From benoit.millot@cstelecom.com Mon Jun 05 00:46:00 2000
From: "Benoit MILLOT" <benoit.millot@cstelecom.com>
To: "gdb@sourceware.cygnus.com" <gdb@sourceware.cygnus.com>
Subject: Symbol file information ?
Date: Mon, 05 Jun 2000 00:46:00 -0000
Message-id: <393B5ADE.73C4BC32@cstelecom.com>
X-SW-Source: 2000-06/msg00041.html
Content-length: 360

Where can i find any information on gdb symbol table?
I works on m68 target. I couldn't read debugging symbol, variables or
functions on gdb from executable file (ieee format issued of microtech
tools).
After compilation and link, the map file contains symbol table. So i
suppose it is possible to convert the map information into gdb symbol
table.

Thanks.