This is the mail archive of the
mailing list for the GDB project.
Re: GDB-5 2000-03-03
- To: ac131313 at cygnus dot com
- Subject: Re: GDB-5 2000-03-03
- From: Mark Kettenis <kettenis at wins dot uva dot nl>
- Date: Fri, 3 Mar 2000 18:14:12 +0100
- CC: gdb-patches at sourceware dot cygnus dot com
- References: <38BFBD74.email@example.com>
Date: Sat, 04 Mar 2000 00:26:12 +1100
From: Andrew Cagney <firstname.lastname@example.org>
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).
Almost nothing appears to have happened for Linux/i386 since you
announced your plans for 5.0 :-(. I haven't heard from JimB yet ...
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.
There are two issue's in the generic x86 code that I'd like to
1. Support for `long double', see:
I wouldn't mind shipping GDB 5.0 without this, but including it
would allow us to clean up some nasty hacks, and get rid of some
2. Adressing the following FIXME in i386-tdep.c:i386_extract_return_value().
/* FIXME: cagney/2000-02-29: This function needs to be rewritten
using multi-arch. Please don't keep adding to this #ifdef
It is possible to modify this function such that it does The Right
Thing for all currenty supported x86 targets.
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
OK! I can't get at the web page directly anyway (are they still in
the old GDB tree? I can only access the new `src' tree.)
Out of control :-)
GNU/Linux/x86 - which?
Overall things (e.g. testsuite results) look OK. Biggest issues seem to
be the dlclose().
There are several more Linux/i386 issues:
The current code doesn't run on Linux 2.x (remember the message you
just sent to Tom):
The FP control registers contain some really weird numbers since the
reserved bits aren't masked of. Patch:
Signal tramplines aren't recognized. Patch:
Programs run under GDB have SIGCHLD masked. No patch yet.
Also look at the "Old problems".
Things that may not make it
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
This seems to happen on Solaris too.
But what about lwpid_t and friends?
This has been fixed:
2000-02-09 Mark Kettenis <email@example.com>
* configure.in: Check for lwpid_t, psaddr_t, prgregset_t and
prfpregset_t in <sys/procfs.h>.
* config.in: Add HAVE_LWPID_T, HAVE_PSADDR_T, HAVE_PRGREGSET_T,
* gdb_proc_service.h: Only provide typedefs for lwpid_t, psaddr_t,
prgregset_t and prfpregset_t if they are not already present.
And has anyone tried multithread debugging?
The testsuite runs OK, but contains a very limited number of tests. I
recently discovered that the thread_db code doesn't handle threads
that exit. See the following URL for more info:
I would consider this a pretty critical bug.
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
There is an official glibc 2.1.3 release now.