From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2545 invoked by alias); 3 Jun 2007 16:37:41 -0000 Received: (qmail 2535 invoked by uid 22791); 3 Jun 2007 16:37:40 -0000 X-Spam-Check-By: sourceware.org Received: from mail.gmx.net (HELO mail.gmx.net) (213.165.64.20) by sourceware.org (qpsmtpd/0.31) with SMTP; Sun, 03 Jun 2007 16:37:37 +0000 Received: (qmail invoked by alias); 03 Jun 2007 16:37:34 -0000 Received: from DSL01.83.171.167.64.ip-pool.NEFkom.net (EHLO localhost) [83.171.167.64] by mail.gmx.net (mp042) with SMTP; 03 Jun 2007 18:37:34 +0200 X-Authenticated: #2360897 Date: Sun, 03 Jun 2007 16:37:00 -0000 From: Bernhard Walle To: gdb@sourceware.org Subject: Re: gdb 6.5 does not open linux kernel core file properly Message-ID: <20070603163826.GA7115@mail1.bwalle.de> References: <20070501104231.GA5204@in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Y-GMX-Trusted: 0 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-06/txt/msg00021.txt.bz2 * Bernhard Walle [2007-06-03 11:27]: > Vivek Goyal wrote: > > I am using GNU gdb Red Hat Linux (6.5-5.fc6rh). > > > > This problem is not present in gdb 6.4. It works perfectly fine. > > I found out that the error appeared with following change: > > cvs diff -u -D "2006-01-24 22:30:00 -0000" -D "2006-01-24 22:40:00 -0000" > > The problem is svr4_solib_create_inferior_hook() -> svr4_relocate_main_executable(). > If I comment out this function, everything works fine. ;-) Should the kernel not mark it's ELF type to ET_DYN (but then it's difficult to distinguish between a relocatable kernel and a unrelocatable kernel)? Or should we add a .interp section to the kernel (but I don't think it's a good idea, it would be more a workaround, IMO). However, the PC which is used to relocate the binary is completely wrong because it's in physical virtual space and the start address is in physical address space. And even if it would be transferred to physical address space, it would not mark the beginning of the kernel (entry point), so it's unusable for relocation. Thanks, Bernhard