This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
GDB-5 2000-03-03
- To: GDB Patches <gdb-patches at sourceware dot cygnus dot com>
- Subject: GDB-5 2000-03-03
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Sat, 04 Mar 2000 00:26:12 +1100
- Organization: Cygnus Solutions
http://sourceware.cygnus.com/gdb/issues50.html
Hello,
I've appended a copy of the above page. Briefly what's happend over the
last week I that hopefully most of the oustanding patches and problems
have ben resolved (or identified).
I've also started identifying things that might not make it into 5.0.
Once the things I've identified as ``out of control'' are ``under
control'' I'll cut a branch.
In the case of ELi's binutils stuff, something more ruthless might be
needed.
Andrew
GDB 5.0 issues
Here are some issues that have been raised vis-a-vis the 5.0 release
(also see the gdb and other mailing lists).
Please route all suggested changes to this page through Andrew Cagney
(release coordinator for 5.0) so that he hopefully doesn't forget them
...
Out of control :-)
MI tests
The MI testsuite falls over (lots of dejagnu errors) when the MI wasn't
build.
HPUX
Recent fixes have hopefully fixed the immediate problems. Need it to be
checked.
Cygwin GDB and INSIGHT
Plenty of recent fixes have gone through. This needs a re-run.
DJGDB
Eli got some outstanding BINUTILS patches :-(
m68k-motorola-sys
Philippe De Muyter writes:
With the gdb cvs tree of 2000-02-19, on m68k-motorola-sys, configure
correctly detect that we have `poll', but gdb incorrectly assumes that
`poll' can
be used to wait for `stdin'. On m68k-motorola-sysv, tty's are not
stream-based and not `poll'able. Should the configure test be enhanced ?
I don't think
so if we need to run a target program to check that, because it would
fail if we cross-compile gdb, but if it can be determined by other ways,
like the
presence of some constants in some header files then I would agree. We
could also always compile in the `poll' version if HAVE_POLL, but switch
to
the the fall-back method at run time if poll fails with POLLNVAL.
HAVE_POLL is not enough It is thought tht --noasync will get around the
problem. Confirm? Alternativly force that to be the default via (ulgh)
xm-*.h
files.
C++ patches
It may be possible to merge in some outstanding C++ patches now that Dan
is the maintainer. Will need to tread carefully thought.
Under control (work in
progress)
Alpha osf and ISO-C
Lots of annoying errors that need fixing.
dlclose()
GDB does not notice when shared libraries are unloaded, in fact it can
get confused. This is a longstanding bug/limitation but one which is
affecting quite
a few people. We have a patch (see Kingdon's subsequent 21 Feb 2000
message for testsuite results).
JimB's is reviewing this patch.
Tom's speedups to GDB
JimB's reviewing this patch.
Solaris/x86 - which?
Nick D's working through patches from Michael Snyder and Peter S.
GNU/Linux/x86 - which?
Overall things (e.g. testsuite results) look OK. Biggest issues seem to
be the dlclose().
Things that may not make
it
Pascal
Command deprecator
GNU/Linux/x86 and random thread signals
Christopher Blizzard writes: So, I've done some more digging into this
and it looks like Jim Kingdon has reported this problem in the past:
threads and spurious SIGTRAPs
I can reproduce this problem both with and without Tom's patch. Has
anyone seen this before? Maybe have a solution for it hanging around? :)
There's a test case for this documented at:
when debugging threaded applications you get extra SIGTRAPs
Shippable
Solaris
Seems to work.
NetBSD/SPARC
This is with a very recent kernel.
# of expected passes 6055
# of unexpected failures 88
# of unexpected successes 1
# of expected failures 190
# of unresolved testcases 59
GNU/Linux/PPC
See Kevins merged it all in.
Hurd/x86
REF to Marks comments...
Unixware
Builds ok. Problems with some of the thread code. Unfortunate but not a
show stopper. Nick D's still looking at it.
Re: uw-threads issues
Old problems
Insight and gdbtcl link: The configury making the link has been moved to
the Makefile.in and is only executed when Insight is being built.
glibc 2.1.3
Most obvious is elf_gregset_t: one fix or another.
But what about lwpid_t and friends?
And has anyone tried multithread debugging?
Of course there is the issue of "which alpha release of glibc 2.1.3?".
Personally I (kingdon) am most worried about the one in Red Hat Linux
6.2beta.