From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16982 invoked by alias); 13 Dec 2001 01:48:11 -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 16917 invoked from network); 13 Dec 2001 01:48:08 -0000 Received: from unknown (HELO localhost.cygnus.com) (205.180.231.71) by sources.redhat.com with SMTP; 13 Dec 2001 01:48:08 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id 663583D60; Wed, 12 Dec 2001 17:48:03 -0800 (PST) Message-ID: <3C1808D3.1020504@cygnus.com> Date: Wed, 12 Dec 2001 17:48:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.6) Gecko/20011207 X-Accept-Language: en-us MIME-Version: 1.0 To: thorpej@wasabisystems.com Cc: msnyder@cygnus.com, Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [RFC] New command 'gcore' References: <3C17D3A0.DE140BFB@cygnus.com> <5567-Thu13Dec2001010400+0200-eliz@is.elta.co.il> <20011212152813.J28715@dr-evil.shagadelic.org> <3C18018E.9080902@cygnus.com> <20011212173359.L28715@dr-evil.shagadelic.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2001-12/txt/msg00335.txt.bz2 > 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). Yes, sorry, I didn't quite say it right. For solaris, GDB presents threads to the user. Underneath the hood, GDB uses lib thread DB to map between LWPs and threads. GDB, here, needs to put the LWP state into the core file. Not the thread state. > 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. But is that GDB's problem? If the procfs / ptrace / ttrace interface is lieing (returning fp registers for the wrong LWP/thread) then we've worse problems than the above :-) enjoy, Andrew