From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3744 invoked by alias); 24 Oct 2004 18:43:15 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 3736 invoked from network); 24 Oct 2004 18:43:14 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 24 Oct 2004 18:43:14 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CLnKk-0003rY-8i; Sun, 24 Oct 2004 14:43:14 -0400 Date: Mon, 25 Oct 2004 09:43:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney , gdb@sources.redhat.com Subject: Re: GDB 6.3 branch 2004-10-16-ish Message-ID: <20041024184314.GA14778@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <41642D8E.6090207@gnu.org> <20041006175540.GB9904@nevyn.them.org> <4164401F.2030201@gnu.org> <20041006190208.GB13130@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041006190208.GB13130@nevyn.them.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-10/txt/msg00408.txt.bz2 On Wed, Oct 06, 2004 at 03:02:08PM -0400, Daniel Jacobowitz wrote: > On Wed, Oct 06, 2004 at 02:57:35PM -0400, Andrew Cagney wrote: > > >On Wed, Oct 06, 2004 at 01:38:22PM -0400, Andrew Cagney wrote: > > > > > >>>The two big lumps appear to have been swallowed - ada and ICU. There's > > >>>still stuff floating around for instance: > > >>> > > >>>- end-of-life deprecated_registers > > >>>- end-of-life xm file (that looks likely to slip) > > >>> > > >>>I might get bored and mark up gdb over the weekend the comming weekend. > > >>> But others, such as the bfd stuff needed to de-hack vsyscall are going > > >>>to have to slip out. > > > > > > > > >Ignoring the de-hacking, how about actually connecting it? > > > > Which system? It's already connected on i386 GNU/Linux right? > > No. The thread "Re: [obish?sym;rfa:doc] Wire up vsyscall" was never > resolved; neither your patch nor mine was committed and both are > needed. > > > >I'm still waiting for the two corresponding failures in corefile.exp to > > >go away. > > > > The de-hack is to fix the failures on corefile and attach :-/ It turns out that the fixes in corefile.exp had nothing to do with vsyscall, but a different local problem on my system. That's because, even without vsyscall wired up, we can stumble through the test well enough to match the regexps: #0 0xffffe410 in ?? () #1 0xbfffe768 in ?? () #2 0x00000006 in ?? () #3 0x000022fc in ?? () #4 0x40081e23 in raise () from /lib/tls/i686/cmov/libc.so.6 #5 0x4008371c in abort () from /lib/tls/i686/cmov/libc.so.6 #6 0x0804869c in func2 () at /big/fsf/projects/vsyscall/src/gdb/testsuite/gdb.base/coremaker.c:127 #7 0x080486a7 in func1 () at /big/fsf/projects/vsyscall/src/gdb/testsuite/gdb.base/coremaker.c:133 #8 0x080486c3 in main () at /big/fsf/projects/vsyscall/src/gdb/testsuite/gdb.base/coremaker.c:139 (gdb) PASS: gdb.base/corefile.exp: backtrace in corefile.exp In any case, in the process of finding that out I updated the vsysall patches. I'll post them. -- Daniel Jacobowitz