From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32483 invoked by alias); 29 Aug 2006 13:36:52 -0000 Received: (qmail 32474 invoked by uid 22791); 29 Aug 2006 13:36:51 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.181) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Aug 2006 13:36:49 +0000 Received: by py-out-1112.google.com with SMTP id x31so2628855pye for ; Tue, 29 Aug 2006 06:36:47 -0700 (PDT) Received: by 10.35.61.2 with SMTP id o2mr14940105pyk; Tue, 29 Aug 2006 06:36:47 -0700 (PDT) Received: by 10.35.35.4 with HTTP; Tue, 29 Aug 2006 06:36:47 -0700 (PDT) Message-ID: Date: Tue, 29 Aug 2006 13:36:00 -0000 From: "chen free" To: "Frederic RISS" Subject: Re: What exactly does "info sharedlibrary" command show? Cc: gdb@sources.redhat.com In-Reply-To: <1156857555.3429.209.camel@crx549.cro.st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1156855634.3429.197.camel@crx549.cro.st.com> <1156857555.3429.209.camel@crx549.cro.st.com> 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/msg00216.txt.bz2 What I'm interested in is the snap-shot of physical memory usage of shared libraries. Yes, maybe I should try other tools. Anyway, thanks, Fred. Regards, Eric 2006/8/29, Frederic RISS : > 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. > >