From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13909 invoked by alias); 13 Dec 2001 01:35:24 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 13342 invoked from network); 13 Dec 2001 01:34:06 -0000 Received: from unknown (HELO dr-evil.shagadelic.org) (208.176.2.162) by sources.redhat.com with SMTP; 13 Dec 2001 01:34:06 -0000 Received: by dr-evil.shagadelic.org (Postfix, from userid 7518) id BA6B3986B; Wed, 12 Dec 2001 17:33:59 -0800 (PST) Date: Wed, 12 Dec 2001 17:35:00 -0000 From: Jason R Thorpe To: Andrew Cagney Cc: msnyder@cygnus.com, Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [RFC] New command 'gcore' Message-ID: <20011212173359.L28715@dr-evil.shagadelic.org> Reply-To: thorpej@wasabisystems.com Mail-Followup-To: Jason R Thorpe , Andrew Cagney , msnyder@cygnus.com, Eli Zaretskii , gdb-patches@sources.redhat.com References: <3C17D3A0.DE140BFB@cygnus.com> <5567-Thu13Dec2001010400+0200-eliz@is.elta.co.il> <20011212152813.J28715@dr-evil.shagadelic.org> <3C18018E.9080902@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C18018E.9080902@cygnus.com>; from ac131313@cygnus.com on Wed, Dec 12, 2001 at 05:17:02PM -0800 Organization: Wasabi Systems, Inc. X-SW-Source: 2001-12/txt/msg00334.txt.bz2 On Wed, Dec 12, 2001 at 05:17:02PM -0800, Andrew Cagney wrote: > > * You need to know if a given chunk of the address space > > should be dumped, even if it is mapped (consider a > > memory-mapped device where reads produce side-effects). > > > That one is more interesting. I suspect it might be best to punt this > and leave finding the solution to those with the problem :-) Eh, I guess. But most Unix systems explcitly skip memory regions that aren't file-backed or anonymous pages, so GDB should skip such regions, too. > To be more exact. On a target such as Solaris where there is an N:M > relationship between (N) threads and (M) LWPs, a LWP iterator would be > needed. You don't really need a thread->lwp mapping. You just need to know how many LWPs there are, and what their lwpids are (so you can fetch their registers and also properly mark the note in the core file with the lwpid). Presumably, the thread->lwp mapping would be contained in the memory image somewhere (e.g. the thread library's scheduler data structures). Actually, another interesting problem... you need to deal with the lazy FP context switching that many Unix systems do, as well. E.g. when a process runs, even if it has previously used the FPU, it may be running on a processor which is different from the last processor it ran on, which means its FPU state could be somewhere else (that is, in another processor's FP registers, NOT in the process's PCB or in the current processor's FP registers), so you need to figure out some way to deal with that, as well. -- -- Jason R. Thorpe