schorr@ead.dsa.com (Andrew J. Schorr) (05/21/91)
The dbx in AIX 3.1.5 (probably previous releases, also) does not cut the mustard for us, and I'm wondering if others have the same problems, comments, etc. Here is the scenario: I have a large program (1 Mbyte binary, links in many shared libraries, totalling around 10 Mbytes) which crashes with the message "Memory fault". This same program runs fine on a Sun, under SunOS 4.1.1. This suggests that either the code is buggy, and just happens to work on the Sun, or the AIX compiler is generating bad code. In any case, I thought that I would debug it and see what was happening. I fired up dbx. Many minutes later, while it was still reading the symbolic information (according to the message it prints), it died (the system ran out of virtual memory). This leaves me with 2 problems: 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)? Perhaps compiling the shared libraries without -g would eliminate this problem? But even so, that shouldn't be necessary. Any comments? -Andy P.S. On the positive side, linking programs with shared (dynamic) libraries is much faster (and uses much less memory) than linking with normal, static libraries. Presumably this is because much of the symbol resolution has already occurred.
cohen@eagle.austin.ibm.com (/100000) (05/21/91)
> 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)? There is a new flag (-f) you can use to speed up start-up time. This flag does what you suggest and reads in symbol table information on demand. Rick Cohen | phone: tl 793-3792 ibm: cohen@eagle.austin.ibm.com | vnet: COHEN at AUSTIN outside: uunet!cs.utexas.edu!ibmchs!auschs!eagle.austin.ibm.com!cohen
marc@stingray.austin.ibm.com (Marc J. Stephenson/140000;1C-22) (05/21/91)
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