Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Nick Savoiu" <savoiu@ics.uci.edu>
To: <gdb@sources.redhat.com>
Subject: Re: Debugging a large program
Date: Mon, 04 Oct 2004 21:15:00 -0000	[thread overview]
Message-ID: <044c01c4aa56$e5f7fb00$5a02a8c0@rio> (raw)

>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


             reply	other threads:[~2004-10-04 21:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-04 21:15 Nick Savoiu [this message]
2004-10-04 21:16 ` Daniel Jacobowitz
2004-10-04 23:21   ` Daniel Jacobowitz
2004-10-04 23:25     ` Nick Savoiu
2004-10-05  5:24       ` Daniel Jacobowitz
2004-10-05 15:26         ` Nick Savoiu
     [not found] <F51E79B1-195C-11D9-ACAD-000A9569836A@gnu.org>
2004-10-08 21:35 ` Jason Molenda
2004-10-11  1:46   ` Daniel Berlin
2004-10-11  6:10     ` Andrew Cagney
2004-10-11 13:59   ` Andrew Cagney
  -- strict thread matches above, loose matches on Subject: below --
2004-10-04 20:48 Nick Savoiu
2004-10-04 20:54 ` Daniel Jacobowitz
2004-10-05 14:05   ` Andrew Cagney
2004-10-05 14:07     ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='044c01c4aa56$e5f7fb00$5a02a8c0@rio' \
    --to=savoiu@ics.uci.edu \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox