home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!ferkel.ucsb.edu!ucsbcsl!network.ucsd.edu!pacbell.com!iggy.GW.Vitalink.COM!cs.widener.edu!dsinc!bagate!cbmvax!jesup
- From: jesup@cbmvax.commodore.com (Randell Jesup)
- Newsgroups: comp.arch
- Subject: Re: Program behaviour (was Re: trapping speculative ops
- Message-ID: <34740@cbmvax.commodore.com>
- Date: 29 Aug 92 23:37:00 GMT
- References: <1992Aug27.202845.10747@bcars64a.bnr.ca> <k7D9PB1w165w@tsoft.sf-bay.org>
- Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
- Organization: Commodore, West Chester, PA
- Lines: 24
-
- bbs.dennis@tsoft.sf-bay.org (Dennis Yelle) writes:
- >schow@bqneh3.bnr.ca (Stanley T.H. Chow) writes:
- >> Some people (including me), believe that there is only *one* level
- >> of optimization. One should always ship the same binary that one
- >> tested;
-
- >I agree. This is why I am annoyed that most linkers put the
- >debug information in the executable file. I think that the
- >debug information should be put in a different file (ending with .dbg
- >perhaps). Then I could test, debug, and ship EXACTLY the same binary.
-
- However, adding some types of debug information can modify the
- generated code, so you have to be careful about it (know your linker/
- compiler/debugger and it's habits). Good linkers have the ability to
- strip debug information out of an executable for shipping, without modifying
- the code you debugged.
-
- --
- "Rev on the redline, you're on your own; seems like a lifetime, but soon it's
- gone..." Foreigner
- -
- Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
- {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup
- Disclaimer: Nothing I say is anything other than my personal opinion.
-