gwyn@smoke.BRL.MIL (Doug Gwyn) (04/21/89)
In article <17615@cisunx.UUCP> jcbst3@unix.cis.pittsburgh.edu (James C. Benz) writes: >If the program is well written and all other things being equal, will the >program take longer to load and will it run slower with the symbols in? The symbols aren't loaded at all, they're just tacked onto the load file. If you have the disk space, there is no reason not to retain the symbols.
luc@spcc386.UUCP (Luc Rooijakkers) (04/21/89)
In article <17615@cisunx.UUCP> jcbst3@unix.cis.pittsburgh.edu (James C. Benz) writes: >Just a little question of some interest. Suppose I have a C program that >when compiled with the -g option (debugging symbols left in) (this is ATT >Unix Sys V). Does leaving these symbols in the file affect program >performance? Not in any way that I know off. Actually, *some* symbol tables are always included in your executable, unless you use strip(1) or the -s option to ld. Any reasonable *IX kernel would just skip the symbol table information when loading your program. So, the only price is in disk space. -- Luc Rooijakkers luc@spcc386.UUCP -or- uunet!mcvax!hp4nl!spcc386!luc
paul@moncam.co.uk (Paul Hudson) (04/21/89)
In article <17615@cisunx.UUCP>, jcbst3@cisunx.UUCP (James C. Benz) writes: > Just a little question of some interest. Suppose I have a C program that > when compiled with the -g option (debugging symbols left in) (this is ATT > Unix Sys V). Does leaving these symbols in the file affect program > performance? Signifigantly? Reason for asking, I have an application .... With "normal" Unix C compilers, -g implies no optimisation. This of course will make your code run slower (usuallly!) than optimised code. It's quite difficult to debug code that has been optimised a lot, although often enough information can be obtained. GNU gcc allows -O and -g to be combined, and thus (except for disk space) there's never any reason to not use -g. Paul Hudson Snail mail: Monotype ADG Email: ...!ukc!acorn!moncam!paul Science Park, paul@moncam.co.uk Milton Road, "Sun Microsysytems: Cambridge, The Company is Arrogant (TM)" CB4 4FQ
guy@auspex.auspex.com (Guy Harris) (04/22/89)
This is a UNIX question, not a C question.... >Just a little question of some interest. Suppose I have a C program that >when compiled with the -g option (debugging symbols left in) (this is ATT >Unix Sys V). Does leaving these symbols in the file affect program >performance? No. >If the program is well written and all other things being equal, will >the program take longer to load and will it run slower with the symbols in? Even if the program is horribly written, the code that implements "exec" was written well enough that it doesn't bother reading the symbol table - it doesn't have to. Unless somebody's botched "exec", it should take no longer to load with the symbols in (modulo any small odd effects such as the last block of the file being larger due to symbols appearing there). The code itself has no idea whether the symbols are present, so it should run no differently with the symbols removed, no matter how well written it is (unless, of course, it knows its own pathname and opens itself to read the symbols, in which case it may not run at all with the symbols stripped; in any case, it shouldn't run slower with the symbols present).
jk@hpfelg.HP.COM (John Kessenich) (04/25/89)
>/ hpfelg:comp.lang.c / jcbst3@cisunx.UUCP (James C. Benz) / 12:32 pm Apr 19, 1989 / > If the program is well written and >all other things being equal, will the program take longer to load and will >it run slower with the symbols in? There may be another issue: security. Consider a program secured through some mechanism (e.g. CPU serial number) by a function in the executable that checks the security mechanism and returns an appropriate value to its calling function, which then acts on the result. If the security function has a meaningful name, having the symbol table present greatly simplifies the task of a user editing the executable to effectively turn off security checks. ---------- John "planning to get a real signature" Kessenich
russ@bbx.UUCP (Russ Kepler) (04/27/89)
In article <690011@hpfelg.HP.COM> jk@hpfelg.HP.COM (John Kessenich) writes: > >There may be another issue: security. Consider a program secured through >some mechanism (e.g. CPU serial number) by a function in the executable >that checks the security mechanism and returns an appropriate value to >its calling function, which then acts on the result. If the security >function has a meaningful name, having the symbol table present greatly >simplifies the task of a user editing the executable to effectively turn >off security checks. If you are using 'strip' for security you should perhaps consider using the '-s' option in 'ld' instead. On one of the systems that we ported to the 'strip' command simply set a pointer/flag to tell 'nm' that there weren't any symbols. File size remained the same. using 'cc -s' generated an executable considerably smaller... -- Russ Kepler - Basis International SNAILMAIL: 5901 Jefferson NE, Albuquerque, NM 87109 UUCP: {backboneishsite}!unmvax!bbx!russ PHONE: 505-345-5232
guy@auspex.auspex.com (Guy Harris) (05/02/89)
>If you are using 'strip' for security you should perhaps consider >using the '-s' option in 'ld' instead. On one of the systems that >we ported to the 'strip' command simply set a pointer/flag to tell >'nm' that there weren't any symbols. File size remained the same. > >using 'cc -s' generated an executable considerably smaller... Then maybe you should consider filing a bug report against the vendor of the system in question.