bobj@aspect.UUCP (Bob Joyce) (06/20/91)
I recently ported a Motif-based program from a Sun Sparc machine to a Motorola MPC 200 running System V. In both cases the program contained a "-g" version of the Motif library. Two things surprised me: (1) The executable size was ~6 Meg on the sparc, but ~13 Meg on the MPC. (2) Starting up the executable on the MPC under gdb took about 20 minutes!. Reason - the process consumed more than 40 Megabytes of memory, thereby causing intense swapping. On the sparc, gdb started up in less than a minute and consumed only about 6 Megs. The same problem occurs with sdb and on another System V, Motorola platform. Is this problem common to System V architectures? Is it particular to Motorola? Have other Motif developers experienced high memory consumption when they compile with "-g"? Do developers have to be very selective about their use of "-g"? Thanks for any information. Bob Joyce uunet!aspect!bobj (408) 441-2236
mjh@alice.att.com (Mike Haertel) (06/22/91)
In article <10570@aspect.UUCP> bobj@aspect.UUCP (Bob Joyce) writes: > (2) Starting up the executable on the MPC under gdb took about > 20 minutes!. Reason - the process consumed more than > 40 Megabytes of memory, thereby causing intense swapping. > On the sparc, gdb started up in less than a minute and consumed > only about 6 Megs. The same problem occurs with sdb and on > another System V, Motorola platform. > >Is this problem common to System V architectures? Is it particular to >Motorola? Have other Motif developers experienced high memory consumption >when they compile with "-g"? Do developers have to be very selective >about their use of "-g"? This is not a property of System V, but rather a property of gdb. On machines that use Berkeley (dbx) style symbols for -g, gdb uses a lazy scheme to only partially read in symbol tables, until they are actually needed. (Randy Smith implemented this.) Nobody has made this work with System V (COFF) symbol tables yet. I imagine it can probably be done. sdb presumably does not use lazy loading of symbols.
jay@retix.retix.com (Jay Logue) (06/25/91)
In article <10570@aspect.UUCP> bobj@aspect.UUCP (Bob Joyce) writes: > > >I recently ported a Motif-based program from a Sun Sparc machine to a Motorola >MPC 200 running System V. In both cases the program contained a "-g" version >of the Motif library. > >Two things surprised me: > > (1) The executable size was ~6 Meg on the sparc, but ~13 Meg on the > MPC. Hmm. Does your system use shared X libraries? I'll bet sun's does. > > (2) Starting up the executable on the MPC under gdb took about > 20 minutes!. Reason - the process consumed more than > 40 Megabytes of memory, thereby causing intense swapping. > On the sparc, gdb started up in less than a minute and consumed > only about 6 Megs. The same problem occurs with sdb and on > another System V, Motorola platform. Sounds like the same problem we encountered: lack of incremental loading of symbols. GDB configured for DBX symbol information does incremental loading (i.e. symbol information is loaded on an as-needed basis). However, GDB configured for use with SDB type symbol information (as it is on most System Vs) does not. All symbols are loaded at start-up time, which for large executables means a long wait and a lot of memory. > >Is this problem common to System V architectures? Is it particular to >Motorola? Have other Motif developers experienced high memory consumption >when they compile with "-g"? Do developers have to be very selective >about their use of "-g"? > I would guess that this is a problem for most if not all implemenations of sdb. Futhermore, I dont think anyone has produced a patch to GDB to allow incremental loading of SDB style symbols. We solved it by using the GCOFF patchs for the gnu tools. (Okay, someone help me out! Who produced these patches?) They modify GCC and GAS to produce DBX style symbols inbeded within SDB records. The resultant .o's can still be linked with the native linker but must be debugged with a patched version of GDB. You get all the benefits of the DBX environment (such as incremental loading and proper handling of symbols information that the ATT assembler cant hack) without having to resort to using the COFF encapsulation stuff. But you have to use GCC/GAS. > > Bob Joyce > uunet!aspect!bobj > (408) 441-2236 > Jay Logue =============================================================================== Retix USMail: 2644 30th Street, Santa Monica, CA 90405-3009 U.S.A Tel: (213) 399-1611 Fax: (213) 458-2685 Telex: 4944307 E-mail: jay@retix.retix.com X.400: C=US;ADMD=TELEMAIL;PRMD=RETIX;O=OSI ONE;S=LOGUE;G=JAY ===============================================================================