Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!romp!auschs!d75!awdprime!stingray.austin.ibm.com!marc
From: marc@stingray.austin.ibm.com (Marc J. Stephenson/140000;1C-22)
Newsgroups: comp.unix.aix
Subject: Re: AIX 3.1 dbx problem
Keywords: AIX dbx virtual memory SLOW
Message-ID: <7780@awdprime.UUCP>
Date: 21 May 91 14:17:59 GMT
References: <1991May20.132212@ead.dsa.com>
Sender: news@awdprime.UUCP
Organization: IBM AWD, Austin
Lines: 47

In article <1991May20.132212@ead.dsa.com> schorr@ead.dsa.com (Andrew J. Schorr) writes:
>1. dbx is using a huge amount of virtual memory.  There were approximately
>   30 Mbytes of virtual memory available when I ran dbx.  I have no idea
>   how much I would need in order for dbx to work.
>2. What is dbx doing on start-up that takes so long?  My guess is that
>   it's building symbol tables (& related activities) for every module
>   in the program, as well as in the shared libraries (which, I should
>   mention, were compiled with the -g flag).  If that is the case, why does
>   dbx need to resolve all this info at start-up?  Can't it delay this stuff
>   and do it as necessary (on a demand basis)?
>Any comments?
>-Andy

As already mentioned, there was a -f flag added for "fast" startup - it
basically forces dbx to read in the symbol table information for a file
only when a function within that file has been "touched."  I believe that
the -f option became available in the 3003 update; it is certainly in 3005/
3.1.5.

You are correct in assuming that dbx is building symbol tables for everything
in the program - it is also building line number tables, function tables,
file tables, and other stuff.  dbx, as you may well know, was ported from
BSD; its design was to gather all of its knowledge at the beginning, then
never have to go back to the object file.  For large programs, this becomes
a memory problem.  For programs with shared libraries (virtually all programs),
the problem gets worse, because dbx cannot easily determine which pieces of
the shared library are pertinent to the program.  dbx can tell which pieces
of the shared library are called by the main executable, but cannot tell
which things are called from within the shared library, so dbx has to read in
the whole thing.  In your typical "hello" program, the "execed" module would
be hello, which contains startup code, main, and a call to printf, which
is in the shared library.  In that scenario, printf is the only call to the
shared library (shr.o in libc.a), but printf calls other things, such as
_doprnt().  dbx has to deal with all of shr.o from libc.a, because it can't
tell what the user is interested in, and can't tell which specific routines
printf would call.  For unshared programs, that was not (and is not) the case.

FYI, dbx also has to relocate all of the addresses, because the link
addresses != load addresses.

Anyway, the -f flag was added to reduce memory consumption and to decrease
startup time.  Hope it works out for you.

-- 
Marc Stephenson		      IBM PSPA (Personal System Programming - Austin,TX)
DISCLAIMER: The content of this posting is independent of official IBM position.
marc@stingray.austin.ibm.com 	VNET: MARC at AUSVMQ  	IBM T/L: 793-3796