From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6434 invoked by alias); 13 Dec 2001 01:17:12 -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 6388 invoked from network); 13 Dec 2001 01:17:08 -0000 Received: from unknown (HELO localhost.cygnus.com) (205.180.231.71) by sources.redhat.com with SMTP; 13 Dec 2001 01:17:08 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id B09FF3D60; Wed, 12 Dec 2001 17:17:02 -0800 (PST) Message-ID: <3C18018E.9080902@cygnus.com> Date: Wed, 12 Dec 2001 17:17: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, msnyder@cygnus.com Cc: 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2001-12/txt/msg00333.txt.bz2 Cool feature of the month comes to mind. Once this is working all sorts of things are possible. > Yah, gcore is cool, but it generally requires support from the kernel > in one way or another: > > * You need to know which chunks of the address space are > actually mapped, and the protection of those regions. ac131313@nettle$ cat /proc/$$/maps 01800000-01880000 r-xp 00000000 0a:05 10177 018b0000-018c5000 rwxp 00070000 0a:05 10177 018c5000-018e7000 rwxp 00000000 00:00 0 418b0000-418c5000 rwxp 00000000 0a:05 93269 418c5000-418c8000 rwxp 00000000 00:00 0 418c8000-418d0000 rw-p 00000000 00:00 0 418d0000-418d2000 r-xp 00000000 0a:05 87796 41911000-41913000 rwxp 00001000 0a:05 87796 41913000-419a6000 r-xp 00000000 0a:05 87369 419e5000-419f2000 rwxp 00092000 0a:05 87369 419f2000-419ff000 rwxp 00000000 00:00 0 7dfff000-7fdff000 ---p 00000000 00:00 0 7fdff000-7fff0000 rwxp 00000000 00:00 0 7fff0000-7ffff000 rwxp 00000000 00:00 0 The wonders of procfs! More seriously, the target vector would need an enhancement to include an address spaces iterator. > * 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 :-) I would note that there is now a memory attribute framework so GDB might be able to extract some of the information from that. A remote target might use a remote query (or just suck the memory it knows is relevant). However, if I were Michael, I'd just get a basic proof of concept done. > * You need to know how many LWPs there are, and need to > be able to iterate over them. Hmm. Yes, good point. 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. Andrew