GDB-5 2000-03-03

[Andrew Cagney <ac131313 at cygnus dot com>]

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.