From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9330 invoked by alias); 13 May 2003 16:03:54 -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 9267 invoked from network); 13 May 2003 16:03:53 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 13 May 2003 16:03:53 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id B2BDA2B2F; Tue, 13 May 2003 12:03:46 -0400 (EDT) Message-ID: <3EC11762.5080708@redhat.com> Date: Tue, 13 May 2003 16:03:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roland McGrath Cc: Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: gdb support for Linux vsyscall DSO References: <200305130229.h4D2Tp723361@magilla.sf.frob.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00219.txt.bz2 Roland, There is no silver bullet. However, there are designs that [I think] provide both GDB and the kernel the best of possible worlds. If the kernel simply dumps out its raw information (instead of cooking it in a way it thinks will be useful to debuggers) then GDB can pick and choose what it really needs. This also means that the core file and live process are both furnishing GDB with identical data. Might even make the kernel cleaner. Andrew