From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6055 invoked by alias); 4 Oct 2004 21:12:42 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 6037 invoked from network); 4 Oct 2004 21:12:41 -0000 Received: from unknown (HELO borg.ics.uci.edu) (128.195.1.103) by sourceware.org with SMTP; 4 Oct 2004 21:12:41 -0000 Received: from rio (c-24-7-116-111.client.comcast.net [24.7.116.111]) by borg.ics.uci.edu (8.12.10/8.12.10) with SMTP id i94LCeoN011810 for ; Mon, 4 Oct 2004 14:12:40 -0700 (PDT) Message-ID: <044c01c4aa56$e5f7fb00$5a02a8c0@rio> From: "Nick Savoiu" To: Subject: Re: Debugging a large program Date: Mon, 04 Oct 2004 21:15:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00063.txt.bz2 >On Mon, Oct 04, 2004 at 01:44:55PM -0700, Nick Savoiu wrote: >> Hi, >> >> I'm using GDB to debug a rather large program and I'm running into memory >> usage problems that slow down debugging considerably. Just invoking GDB on >> the executable (without issuing 'run') results in GDB using up 450MB of >> memory. >> >> I think that this is caused by GDB reading in all the symbol info. However, >> the code that I'm debugging uses but a small fraction of the code that's >> present in the program. Can I somehow tell GDB to only load the symbols it >> needs? > >GDB already reads in only what it needs, and more lazily - however, >there's some information about every symbol that's needed. 450MB is >pretty remarkable; how big is the application? readelf -S output would >be the best way to answer the question. Here's what readelf -S says: There are 30 section headers, starting at offset 0x57ec: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .interp PROGBITS 080480f4 0000f4 000013 00 A 0 0 1 [ 2] .note.ABI-tag NOTE 08048108 000108 000020 00 A 0 0 4 [ 3] .hash HASH 08048128 000128 000054 04 A 4 0 4 [ 4] .dynsym DYNSYM 0804817c 00017c 000100 10 A 5 1 4 [ 5] .dynstr STRTAB 0804827c 00027c 002a23 00 A 0 0 1 [ 6] .gnu.version VERSYM 0804aca0 002ca0 000020 02 A 4 0 2 [ 7] .gnu.version_r VERNEED 0804acc0 002cc0 000020 00 A 5 1 4 [ 8] .rel.dyn REL 0804ace0 002ce0 000008 08 A 4 0 4 [ 9] .rel.plt REL 0804ace8 002ce8 000010 08 A 4 b 4 [10] .init PROGBITS 0804acf8 002cf8 000018 00 AX 0 0 4 [11] .plt PROGBITS 0804ad10 002d10 000030 04 AX 0 0 4 [12] .text PROGBITS 0804ad40 002d40 0000f0 00 AX 0 0 16 [13] .fini PROGBITS 0804ae30 002e30 00001e 00 AX 0 0 4 [14] .rodata PROGBITS 0804ae50 002e50 000008 00 A 0 0 4 [15] .data PROGBITS 0804b000 003000 00000c 00 WA 0 0 4 [16] .eh_frame PROGBITS 0804b00c 00300c 000004 00 WA 0 0 4 [17] .dynamic DYNAMIC 0804b010 003010 0004a8 08 WA 5 0 4 [18] .ctors PROGBITS 0804b4b8 0034b8 000008 00 WA 0 0 4 [19] .dtors PROGBITS 0804b4c0 0034c0 000008 00 WA 0 0 4 [20] .jcr PROGBITS 0804b4c8 0034c8 000004 00 WA 0 0 4 [21] .got PROGBITS 0804b4cc 0034cc 000018 04 WA 0 0 4 [22] .bss NOBITS 0804b4e4 0034e4 000004 00 WA 0 0 4 [23] .stab PROGBITS 00000000 0034e4 0007a4 0c 24 0 4 [24] .stabstr STRTAB 00000000 003c88 001983 00 0 0 1 [25] .comment PROGBITS 00000000 00560b 0000c2 00 0 0 1 [26] .note NOTE 00000000 0056cd 00003c 00 0 0 1 [27] .shstrtab STRTAB 00000000 005709 0000e3 00 0 0 1 [28] .symtab SYMTAB 00000000 005c9c 000470 10 29 34 4 [29] .strtab STRTAB 00000000 00610c 0001cf 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) BTW, 405MB was for gdb running to main() not just what I said above :) There probably are a few global variables but I don't think they should take up too much space. Nick