From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24266 invoked by alias); 29 Aug 2006 13:20:51 -0000 Received: (qmail 24256 invoked by uid 22791); 29 Aug 2006 13:20:50 -0000 X-Spam-Check-By: sourceware.org Received: from fra-del-04.spheriq.net (HELO fra-del-04.spheriq.net) (195.46.51.100) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Aug 2006 13:20:41 +0000 Received: from fra-out-03.spheriq.net (fra-out-03.spheriq.net [195.46.51.131]) by fra-del-04.spheriq.net with ESMTP id k7TDKc9j004264 for ; Tue, 29 Aug 2006 13:20:38 GMT Received: from fra-cus-02.spheriq.net (fra-cus-02.spheriq.net [195.46.51.38]) by fra-out-03.spheriq.net with ESMTP id k7TDKbhi023553 for ; Tue, 29 Aug 2006 13:20:38 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-02.spheriq.net with ESMTP id k7TDKXCj003291 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 29 Aug 2006 13:20:37 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id BE853DA4F; Tue, 29 Aug 2006 13:20:21 +0000 (GMT) Received: from mail1.cro.st.com (mail1.cro.st.com [164.129.40.131]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 3B83F47467; Tue, 29 Aug 2006 13:20:21 +0000 (GMT) Received: from crx549.cro.st.com (crx549.cro.st.com [164.129.44.49]) by mail1.cro.st.com (MOS 3.5.8-GR) with ESMTP id CIH67023 (AUTH "frederic riss"); Tue, 29 Aug 2006 15:19:15 +0200 (CEST) Subject: Re: What exactly does "info sharedlibrary" command show? From: Frederic RISS To: chen free Cc: gdb@sources.redhat.com In-Reply-To: References: <1156855634.3429.197.camel@crx549.cro.st.com> Content-Type: text/plain Date: Tue, 29 Aug 2006 13:20:00 -0000 Message-Id: <1156857555.3429.209.camel@crx549.cro.st.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00213.txt.bz2 On Tue, 2006-08-29 at 21:00 +0800, chen free wrote: > Yes, it a tough job, maybe I have to dump the memory image and look > into it. BTW, the "dump" command of GDB is also only able to dump > process' own virtual memory space ? Because when I try to dump > physical memory address range, the result is all zeros....I tried this > on 2.6 kernel Usually a process has only access to its virtual address space, thus accessing physical memory ranges might not even be possible. Even if you can access the physical memory, it's most of the time just pointless because the data is loaded in memory only on-demand (upon a pagefault). That's why I said it's a tough job. Memory usage is hard to define when you deal with code that is shared among processes and loaded only when necessary... But we're diverging from GDB. I don't know exactly what 'memory usage' you want to monitor, but maybe GDB isn't the right tool for what you want to do (debugger vs profiler?) Fred.