From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21622 invoked by alias); 26 Oct 2007 19:08:01 -0000 Received: (qmail 21606 invoked by uid 71); 26 Oct 2007 19:08:01 -0000 Date: Fri, 26 Oct 2007 19:08:00 -0000 Message-ID: <20071026190801.21605.qmail@sourceware.org> To: nobody@sources.redhat.com Cc: gdb-prs@sources.redhat.com, From: Daniel Jacobowitz Subject: Re: gdb/2347: gdb 6.7 can't attach to process Reply-To: Daniel Jacobowitz Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org X-SW-Source: 2007-q4/txt/msg00088.txt.bz2 The following reply was made to PR gdb/2347; it has been noted by GNATS. From: Daniel Jacobowitz To: "Paul M. Dubuc" Cc: gdb-gnats@sourceware.org Subject: Re: gdb/2347: gdb 6.7 can't attach to process Date: Fri, 26 Oct 2007 14:59:35 -0400 (Please use reply-to-all so that this can be logged in the build system.) On Fri, Oct 26, 2007 at 02:49:44PM -0400, Paul M. Dubuc wrote: > I got the 32-bit version to build by setting --build=i686-redhat-linux instead. Yes, sorry. Sometimes you need both. > Now that I get the 32-bit version built and running, I notice it still has a > problem that we've been having with earlier versions of GDB. When we attach to > a process and do a gcore, we can't read the resulting core file back in without > the following errors and corrrupt stack trace: > (gdb) where > #0 0xffffe410 in __kernel_vsyscall () > (gdb) where > #0 0xffffe410 in ?? () I assume this is just a missed feature in gcore; it needs to learn that it has to dump the vDSO to disk. 64-bit doesn't use a vDSO so you do not encounter this bug. -- Daniel Jacobowitz CodeSourcery